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Preface 


The  purpose  of  this  document  is  to  effectively  communicate  the  system  level  requirements  of  the 
Navigation  in  a  GPS  Denied  Environment  (NAVGPSDE)  system  that  is  under  analysis  /  development  as 
part  of  the  ONR  BAA06-007  contract.  The  information  within  this  document  was  generated  by  the 
Mercury  Data  Systems  development  team  and  is  based  on  data  found  in  the  BAA  solicitation  /  SOW,  the 
MDS  proposal  to  the  solicitation  and  descriptions  of  the  proposed  solution  analysis  and  design  activities. 
The  information  within  this  document  will  be  utilized  in  conjunction  with  the  Concept  of  Operations 
Document  to  provide  an  overall  functional  picture  of  the  proposed  system.  This  document  will  be  provided 
to  the  ONR  project  management  resources  and  end  user  community  to  ensure  the  documented  system 
requirements  meet  the  needs  of  the  users  and  to  ensure  that  the  development  team  fully  understands  the 
functionality  of  the  targeted  system.  To  that  end  this  document  will  be  continually  updated  throughout  the 
life  cycle  of  the  project  during  Phase  I  Analysis  and  Phase  II  Design  /  Construction  efforts  to  allow  for 
changes  in  direction  as  new  requirements  or  system  limitations  are  identified.  The  content  of  this  document 
is  based  on  the  end  user  view  of  the  system,  if  any  content  is  found  to  be  inaccurate,  misleading,  erroneous 
or  incomplete  please  notify  the  document  owner  as  soon  as  possible.  See  the  document  control  section  for 
contact  information. 
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1  Introduction 

1.1  System  Purpose 

The  system  to  be  developed  under  the  initiative  for  the  ONR  BAA  06-007  will  improve  the  way  that 
ground  forces  track,  locate  and  report  their  physical  position  to  both  their  immediate  neighbors  and  to 
higher  headquarters  in  order  to  reduce  fratricide.  Furthermore,  the  system  will  improve  ground  force 
position  location  information  in  GPS  denied  /  limited  GPS  environments. 

1.2  System  Scope 

A  position  and  location  prototype  system  will  be  developed  as  a  result  of  the  requirements  definition  herein 
and  the  subsequent  development  phase.  The  positioning  system  will  attempt  to  reduce  the  occurrence  of 
fratricide  during  ground  force  operations  by  increasing  the  spatial  awareness  of  personnel  location  across 
the  battlefield. 

1.3  Definitions,  Acronyms,  and  Abbreviations 

This  section  includes  a  bulleted  list  of  all  applicable  definitions,  acronyms  and  abbreviations  utilized  within 
the  document. 

•  A-GPS  -  Assisted  GPS 

•  AO  -  Area  of  Operation 

•  BAA  -  Broad  Agency  Announcement 

•  C2  -  Command  and  Control 

•  CMR  -  Clique  Member  Radio 

•  DGPS  -  Differential  GPS 

•  DOP  -  Dilution  of  Precision 

•  EGNOS  -  European  Geostationary  Navigation  Overlay  Service 

•  FBCB2  -  Force  Battle  Command  Brigade  and  Below 

•  F OM  -  F igure  of  Merit 

•  GPS  -  Global  Positioning  System 

•  GUI  -  Graphical  User  Interface 

•  HDOP  -  Horizontal  Dilution  of  Precision 

•  HUD  -  Heads  Up  Display 

2 

•  I  C  -  Inter-Integrated  Circuit 

•  INS  -  Inertial  Navigation  System 

•  JTRS  -  Joint  Tactical  Radio  System 

•  JVMF  -  Joint  Variable  Message  Format 

•  LOS  -  Line  of  Sight 

•  LSE  -  Least  Squared  Error 

•  MANET  -  Mobile  Ad-hoc  Network 

•  MSAS  -  Multi-functional  Satellite  Augmentation  System 

•  MSE  -  Minimum  Squared  Error 

•  NMEA-0183  -  National  Marine  Electronics  Association  0183  Interface  Standard.  Defines 
electrical  signal  requirements,  data  transmission  protocol  and  time,  and  specific  sentence  formats 
for  a  4800-baud  serial  data  bus. 

•  ONR  -  Office  of  Naval  Research 

•  PDOP  -  Position  Dilution  of  Precision 

•  PPP  -  Point-to-Point  Protocol 

•  PPS  -  Precise  Positioning  Service 

•  RF  -  Radio  Frequency 

•  SAASM  -  Selective  Availability  Anti-Spoofing  Module 
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•  SEP  -  Spherical  Error  Probability 

•  SINCGARS  -  Single  Channel  Ground  and  Airborne  Radio  System 

•  SMS  -  Short  Message  Service 

•  SPI  -  Serial  Peripheral  Interface 

•  TDS  -  TOA-based  Data  Screening 

•  TOA  -  Time-of-Arrival  Radio  Frequency  Ranging 

•  TOC  -  Tactical  Operations  Center 

•  TRPS  -  TOA-based  Ranging  Partner  Selection 

•  TTFF  -  Time  to  First  Fix 

•  TTL  -  Time-to-Live 

•  USB  -  Universal  Serial  Bus 

•  VDOP  -  Vertical  Dilution  of  Precision 

•  VGA  -  Video  Graphics  Array.  A  standard  for  graphics  displays,  implying  a  resolution  of  640x480 
pixels,  defined  by  IBM. 

•  WAAS  -  Wide  Area  Augmentation  System 

1.4  References 


The  following  documents  were  utilized  as  references  to  generate  content  for  this  document: 

•  External  System  Interface  Documentation/Specifications  (Military/SINCGARS  radio,  JTRS, 
JVMF,  FBCB2,  etc.) 

•  IEEE  Std  1233-1998  Guide  for  Developing  System  Requirements  Specifications 

•  ONR  BAA  Announcement  #  BAA  06-007 

•  ONRP_ConOps_ONRBAA06-007.pdf,  ONR  BAA06-007  Concept  of  Operations  Document,  v 
1.0,  3/12/2007,  source  -  Mercury  Data  Systems,  Inc. 

•  ONRP_TechReport_ONRBAA06-007.pdf,  ONR  BAA06-007  Final  Technical  Report,  v  1.0, 
3/12/2007,  source  Mercury  Data  Systems,  Inc. 

•  Solicitation  No.  HDTRA1-05-R-0005  titled  Global  Positioning  System  -  Denied  Navigation  and 
Mapping 

1.5  System  Overview 

In  the  current  battlefield  environment,  our  ground  forces  are  often  deployed  in  environments  where  GPS  is 
either  partially  or  completely  unavailable.  An  example  of  partial  denial  includes  operations  in  urban  terrain 
where  buildings  limit  satellite  visibility.  Operations  either  underground  or  inside  of  buildings  prevent  all 
satellite  visibility,  as  well  as  affecting  general  Radio  Frequency  (RF)  propagation.  Therefore,  an  accurate 
position  and  location  system  is  required  that  will  operate  in  these  environments. 

Nominally,  each  Marine  will  carry  a  lightweight  device  capable  of  reporting  its  own  location,  as  well  as 
reporting  the  location  of  the  other  members  of  its  clique  (where  a  clique  is  defined  as  a  group  of 
devices/Marines  that  are  operating  together).  These  devices  shall  cooperate  with  each  other  in  order  to 
provide  a  position  estimate. 

Often,  knowledge  of  the  relative  positions  of  the  other  members  of  the  clique  is  more  important  than  their 
absolute  position.  An  example  of  this  would  be  the  knowledge  that  a  fire  team  is  in  position  on  the  other 
side  of  a  building  prior  to  a  forced  entry.  There  shall  be  a  method  of  determining  one’s  own  position  and  of 
associating  devices  into  a  clique.  In  order  to  permit  higher  headquarters  to  have  knowledge  of  personnel 
location,  at  least  one  device  shall  have  a  standard  military  radio  interface  in  order  to  transmit 
position/location  data.  Information  presentation/display  shall  be  minimal,  preferably  graphical  and  shall 
note  when  position  location  is  degraded.  A  complete  windowing  environment  is  discouraged  due  to  its 
unnecessary  complexity  for  a  fixed  function  device. 
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2  Description,  Capabilities,  Goals,  Assumptions  and  Dependencies 

2.1  System  Description 

A  primary  requirement  of  the  position  and  location  system  to  be  developed  under  the  ONR  BAA  06-007 
initiative  will  be  to  fuse  position  estimates  from  a  variety  of  sources.  The  primary  position  sensors  include 
Global  Position  System  (GPS),  Terrestrial  Time-of-Arrival  (TOA),  and  Inertial  Navigation  System  (INS). 
Figure  1  depicts  the  significant  interfaces  that  will  be  required  across  the  system’s  boundaries.  Items 
enclosed  by  dashed  lines  are  considered  additional/optional  components  that  may  improve/extend  the  core 
functionality  of  the  system  in  the  future. 


Figure  1:  Geo-location  Core  and  Significant  System  Interfaces. 
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Minimally,  each  soldier  will  be  equipped  with  a  positioning  system  that  is  composed  of  a  GPS  component, 
an  INS  component,  an  RF  Communication  and  TOA  Ranging  component,  a  GEO-Location  Core 
Processing  Unit,  and  a  Display  Interface.  The  GEO-Location  Core  shall  provide  I/O  access  to  the  various 
local  position  sensors  and  shall  implement  advanced  fusion  algorithms  in  order  to  produce  an  enhanced 
local  position  estimate  based  upon  the  data  available  from  the  various  position  sensors.  The  fused  position 
estimate  produced  by  the  GEO-Location  Core  shall  be  viewable  by  each  soldier  on  a  simple  graphical 
display.  The  fused  position  estimate  shall  also  be  encrypted  with  NSA  Suite  B  compatible  data  security 
before  it  is  eventually  shared  amongst  clique  members  and  the  Command  and  Control  (C2)  center  via  the 
RF  communication  component.  Furthermore,  each  individual’s  local  positioning  system  shall  receive  the 
position  estimates  of  other  members  in  the  clique  as  well  as  those  from  additional  data  sources  (i.e.  beacons 
and/or  relays),  decrypt  the  data,  and  if  the  received  position  information  is  determined  to  be  reliable,  fuse 
the  data  with  the  local  position  estimate  to  further  enhance  position  accuracy  at  the  individual  and/or  group 
level.  Each  individual  in  the  clique,  including  C2,  shall  receive  available  position  data  of  other  clique 
members/data  sources  that  will  also  be  presented  via  each  individual’s  graphical  display  unit,  enabling 
shared  situational  awareness  throughout  the  operating  clique  as  well  as  at  the  command  level.  Finally, 
limited,  text-based  data  transfer  will  be  supported  by  each  system  in  order  to  provide  a  Short  Message 
Service  within  the  clique. 

2.2  System  Modes  and  States 

The  personnel  tracking  system  should  operate  in  3  navigation  modes  and  provide  a  status  indicator  for  the 
current  mode  to  the  user.  The  modes  that  shall  be  supported  include: 

•  GPS  Enabled  mode  -  GPS  signal  strength  and  VDOP/HDOP  are  low  enough  to  allow  continuous 
personnel  navigation  and  tracking  by  GPS 

•  GPS  Restricted  mode  -  GPS  signal  strength  and/or  VDOP/HDOP  vary  and  do  not  allow 
continuous  personnel  navigation  and  tracking  by  GPS  alone 

•  GPS  Denied  mode  -  GPS  signal  strength  and/or  VDOP/HDOP  are  too  high  to  allow  continuous 
personnel  navigation  and  tracking  by  GPS  at  all 

Status  indicators  should  also  be  made  available  to  the  user  relative  to  these  navigation  modes.  They  are  the 
following: 

•  The  state  of  the  position  sensors  currently  being  used  for  navigation  (GPS,  INS,  TOA, 
degraded/unreliable) 

•  The  state  of  the  network  link  (Connected,  Degraded,  Disconnected) 

2.3  Major  System  Capabilities 

The  major  system  capabilities  are  organized  by  technical  challenge  areas  (major/minor)  based  upon  the 
perception  of  their  relevance  to  the  program  and  upon  the  level  of  effort  that  will  be  required  for  each  area. 


2.3.1  Accurate  Personnel  Tracking  (Major  Technical  Challenge) 

The  accuracy  of  personnel  tracking  systems  is  often  expressed  as  position  error  relative  to  distance 
traveled,  i.e.  2%  of  distance  traveled.  The  personnel  tracking  accuracy  requirement  for  this  project  is  25m 
Spherical  Error  Probable  (SEP).  At  first  glance,  this  requirement  appears  to  require  only  moderate 
performance,  but  when  considered  as  a  percentage  of  distance  traveled,  the  desired  accuracy  translates  into 
a  very  high  performance  requirement  -  0.25%  of  distance  traveled  (25m  SEP/lOKm).  An  absolute 
positioning  source,  such  as  GPS,  may  only  be  available  at  mission  initiation,  so  periodic  synchronization 
with  an  absolute  reference  may  not  be  possible.  To  achieve  such  high  level  of  absolute  accuracy,  a  multi¬ 
sensor  positioning  system  initialized  by  an  absolute  source  and  aided  by  advanced  sensor  fusion  algorithms, 
shall  be  designed  and  developed. 
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2.3.2  Collaborative  Personnel  Tracking  (Major  Technical  Challenge) 

If  GPS  is  denied  at  mission  initiation,  due  to  jamming  or  even  mission  location,  the  clique  will  establish, 
and  operate  under,  an  alternate  referential  coordinate  system.  If  the  starting  coordinates  for  clique  personnel 
are  established  via  GPS;  an  independent  referential  coordinate  system  relative  to  the  starting  coordinates 
shall  be  established  and  maintained  throughout  the  mission  operation. 

At  all  times,  each  clique  member  must  be  able  to  self  localize  their  own  position  and  to  visualize  the 
positions  of  all  members  of  the  clique.  Over  time,  the  accuracy  of  these  self/remotely  localized  position 
estimates  may  deteriorate,  which  will  result  in  divergences  among  the  individual  perspectives  of  the 
coordinate  system.  Even  when  self  localized  positions  are  maintained  within  the  desired  SEP,  a  very 
divergent  group  perspective  of  the  coordinate  system  and  the  positions  of  clique  members  may  evolve. 

An  overarching  alternate  coordinate  system  shall  be  maintained,  across  the  clique,  which  can  supersede  the 
inevitable  divergences  among  position  estimates  that  will  result  as  clique  members  navigate  between  the 
different  types  of  environments.  A  consistent  understanding  of  the  relative  positions  of  all  clique  personnel 
shall  be  established  and  distributed  -  both  to  effectively  organize  mission  operations  and  to  minimize 
divergences  among  individually  localized  position  estimates. 

To  establish  and  maintain  the  alternate  referential  coordinate  system,  methods  to  implement  a  mobile  ad 
hoc  network  that  incorporates  two-way  TOA  ranging  techniques  shall  be  designed.  Additionally,  a 
distributed  voting  algorithm  process  will  be  provided  to  maintain  the  integrity  of  the  referential  coordinate 
system;  to  reconcile  divergences  among  clique  position  estimates;  and  to  disseminate  a  converged  clique 
position  estimate. 

The  alternate  coordinate  system  must  be  able  to  survive  any  single  point  of  failure,  which  requires  design 
and  development  of  methods  to  support  cross  network  data  replication  and  automated  failover  support 
among  focal  nodes  for  the  coordinate  system. 


2.3.3  Visualization  (Minor  Technical  Challenge) 

The  prototype  positioning  system  shall  include  a  lightweight,  graphical  user  interface  (GUI)  -  a  complete 
windowing  system  is  discouraged  due  to  its  unnecessary  complexity  for  a  fixed  function  device.  At  all 
times,  each  Marine  must  be  able  to  visualize  the  relative  positions  of  other  clique  personnel  via  the  GUI  - 
even  if  their  individually  localized  position  relative  to  a  starting  point  has  been  lost.  Each  Marine  shall  also 
be  able  to  visualize  other  clique  personnel  and  locate  the  distance  and  orientation  to  each.  As  well,  each 
Marine  shall  be  able  to  visualize  parameters  for  position  estimate  precision,  network  connectivity,  and 
beacon  locations.  The  ability  to  interact  with  Short  Message  Services  (SMS)  shall  also  be  provided  by  this 
interface.  Lastly,  the  boundaries  between  cliques  may  intersect  and  each  Marine  shall  be  able  to  visually 
identify  members  of  other  cliques  as  they  approach,  this  ability  will  be  provided  as  a  future  system 
enhancement. 

2.3.4  Communications  (Minor  Technical  Challenge) 

Mobile  Ad-Hoc  communications/network  capabilities  shall  be  designed  and  developed  to  support 
autonomous  sharing  of  personnel  positioning  information.  The  Communications  component  shall  include 
five  additional  capabilities: 


2. 3. 4. 1  Locating  Beacons 

The  system  nodes  will  be  able  to  function  as  mobile/portable  beacons  to  augment  accurate  positioning 
and  to  extend  communication  range  for  Non-Line-of-Sight  (NLOS)  environments.  Simple  methods  to 
initialize  and  display  beacon  ID’s  and  coordinates,  as  well  as  communicate  and  range  with  such 
beacons  shall  be  developed. 
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2. 3. 4. 2  Data  Transfer  Security 

All  cryptographic  operations  to  secure  both  data  at  rest  and  in  transit  shall  meet  Suite  B  security 
requirements  (see  Section  3.3.1  for  more  info). 

2. 3. 4. 3  Text  Messaging  / Short  Message  Service  (SMS) 

Limited  text-based  messaging  /  Short  Message  Service  (SMS)  shall  be  supported  between  clique 
personnel,  and  clique  groups. 

2. 3. 4. 4  Assimilation 

During  navigation,  the  boundaries  between  cliques  may  intersect;  the  positions  of  Marines  within  the 
intersecting  areas  must  be  recognized  and  disseminated  across  the  intersecting  cliques.  Since  the 
coordinate  reference  systems  of  the  intersecting  cliques  may  differ,  the  position  estimates  of  the 
Marines  within  the  intersecting  area  may  also  differ  -  perhaps,  even  to  the  point  that  the  position 
estimates  of  physically  separated  Marines  display  that  they  are  both  at  the  same  coordinates. 

When  cliques  intersect,  the  Marines  within  the  intersecting  area  must  be  assimilated  within  the 
coordinate  reference  system  of  the  destination  clique.  The  destination  clique  must  also  acknowledge 
the  hierarchy  and  the  identity  of  the  Marine,  and  the  Marine’s  relative  position  must  be  disseminated 
throughout  the  destination  clique.  If  the  Marine  must  be  permanently  assimilated,  a  process  must  be 
initiated  to  transform  the  coordinate  reference  system  of  the  Marine  to  that  of  the  destination  clique. 

To  avoid  friendly  fire  incidents  during  these  intersections,  autonomous  and  manual  processes  shall  be 
developed  to  assimilate  Marines  within  intersecting  AO’s. 

Note:  Clique  Assimilation  will  not  be  addressed  as  part  of  the  prototype  system,  but  shall  be 
incorporated  into  the  system  as  an  enhancement  post  completion  of  field  trails  prior  to  creation  of  the 
production  hardware  /  software. 

2. 3. 4. 5  Military  Radio  Interface 

The  system  must  provide  a  standard  military  radio  interface  (mechanical,  electrical,  data). 

2.3.5  Ease  of  Use  (Minor  Technical  Challenge) 

The  prototype  positioning  system  shall  require  minimal-to-no  user  training;  hence,  a  human-machine 
interface  that  supports  minimal  user  interaction  shall  be  incorporated  into  the  system  design.  The  system 
initialization  processes  should  be  automated  so  that  they  execute  and  establish  the  user’s  position  when  the 
user  turns  the  system  on.  The  GUI  and  SMS  service  shall  be  easy  to  use  and  shall  not  distract  the  clique 
personnel  from  their  mission  duties.  Lastly,  automated  processes  shall  facilitate  geo-location  of  beacons 
based  upon  the  user’s  coordinates  and  the  TOA  measurements  between  the  user’s  system  and  the  placement 
of  the  beacon. 

2.4  Major  System  Goals 

It  is  not  anticipated  that  the  prototype  system  will  meet  all  the  major  system  goals  of  this  project,  nor  is 
such  a  requirement.  Meeting  the  personnel  tracking  capabilities  through  the  development  of  an  integrated 
system  that  achieves  an  unobtrusive  form  factor  is  the  major  objective  and  technical  challenge  of  this 
program  and  the  efforts  towards  these  challenges  shall  take  precedence  over  these  goals.  However,  the 
goals  should  be  targeted  as  closely  as  possible  and  are  included  to  serve  as  guidelines  during  the  design  and 
development  phase(s). 
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2.4. 1  GPS-denied  Position  Accuracy 

Position  accuracy  in  a  GPS-denied  environment  shall  be  25m  SEP  (Spherical  Error  Probability)  or  better 
after  eight  hours  of  operation. 


2.4.2  Size,  Weight  and  Power  (SWAP) 

2. 4. 2.1  Size 

Volume  of  each  unit  shall  be  400  cm3  (24.4  inches3)  or  less. 

2. 4. 2. 2  Weight 

Unit  mass  shall  be  1kg  or  less,  not  including  battery. 

2.4.23  Power 

Each  unit  shall  operate  for  8  hours  (or  more)  upon  recharge  from  a  single  BA5590  battery  (170  WH) 

capacity. 

2.4.3  Cost 

Projected  production  cost  per  unit  in  quantity  of  1000  shall  be  $2K  or  less. 

2. 4. 4  Prototype  Delivery 

A  minimum  of  five  (5)  positioning  units  are  to  be  produced  and  delivered  in  Phase  II.  If  beacons  and/or 
relays  are  required  to  meet  the  system  capabilities  defined  herein,  a  maximum  of  three  (3)  shall  be 
produced  and  delivered  in  Phase  II. 

2.5  User  Characteristics  /  Roles 

The  system  will  require  establishing  distinct  user  types  and  roles.  The  roles  are  based  on  functional 
responsibilities  for  the  system  end  user;  there  shall  be  no  restricted  access  to  the  UI  features  based  on  role. 
The  Logistics  support  resources  shall  utilize  a  wireless  network  connection  to  access/download  the  system 
data  to  support  system  pre-mission  configuration;  he  will  not  require  access  to  the  UI  unless  he  is  testing 
the  unit  post  maintenance  or  repair  activities. 

•  Logistics  user  -  this  user  will  be  a  technical  resource  similar  to  the  radio  technician  who  will  be 
responsible  for  establishing  clique  node  identification,  ranging  partner  tables,  communications 
channels  /  partners  for  text  messaging,  selection  and  calibration  of  mission  maps  for  the  clique, 
setup  for  each  system  to  be  deployed  with  the  dismounted  resources.  They  will  also  provide  pre¬ 
configuration  and  setup  for  the  location  beacons  if  used  by  the  system  and  Assisted  GPS  data  for 
the  Area  of  Operation.  This  resource  will  have  to  be  a  part  of  the  unit  and  will  need  to  have  access 
to  all  mission  parameters  /  plans  in  order  to  accurately  setup  the  system  prior  to  team  deployment. 

•  Team  Lead  -  this  user  will  be  the  lead  resource  associated  with  the  various  USMC  unit  levels. 
Fire  Team  Lead  -  Fire  Team  Level,  Squad,  Platoon,  etc.  These  users  will  be  primarily  responsible 
for  configuration  /  deployment  of  fixed  position  beacons  if  used,  assimilation  of  new  clique 
members  and  communication  with  the  command  center  or  next  higher  level  team  leader.  This  user 
will  also  make  decisions  on  when/where  to  enable  the  remote  system  zeroize  feature. 

•  Soldier  -  this  user  will  be  the  basic  system  user,  they  will  have  access  to  all  system  features. 
When  directed  they  will  support  the  decisions  of  the  team  lead.  All  users  will  also  have  access  to 
the  map  user  options  (map  selection,  measuring  distance/angle,  system  zeroize  local  and  remote, 
etc...) 
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2.6  Assumptions  and  Dependencies 


2. 6. 1  General 

1 .  Assumed  that  one-  or  two-way  transfer  of  textual  information  is  used. 

2.  Assumed  that  an  accuracy  of  25m  is  desired  (95%  SEP). 

3.  Assumed  that  a  simple  2D  graphical  display  is  sufficient. 

4.  Assumed  that  the  communication  links  (for  data  transfer)  between  nodes  incorporates  the  NSA 
Suite  B  security  standard. 

5.  Assumed  that  the  device  will  be  employed  and  is  required  to  operate  in  a  wide  variety  of 
environments  (see  terrain  list). 

6.  Assumed  that  we  are  not  concerned  with  GPS-jamming. 

7.  The  reduction  of  fratricide  and  the  ability  to  maneuver  in  a  coordinated  fashion  without  explicit 
communications  via  sharing  of  accurate  position  data  with  all  clique  members  is  the  main  premise 
of  the  system. 

8.  Assumed  that  a  military  radio  will  be  available  to  at  least  one  member  in  the  clique. 

9.  Assumed  that  access  to  the  military  radio  is  provided  in  case  node/clique  positions  are  to  be 
transmitted  to  higher  headquarters  -  the  platoon  leader  will  send  data  to  higher  headquarters. 

10.  Assumed  that  preference  will  be  given  to  three  dimensional  (3D)  positioning  with  fallback  to  a 
two  dimensional  (2D)  position  location. 

1 1 .  Assumed  that  the  maximum  potential  distance  traveled  by  the  intended  user  within  the  8  hrs  of 
operation  is  10km  radial  area  (10  km  linear  distance  -  straight  line  or  random  walk). 

12.  Uninterrupted  operation,  over  duration  of  8  hours  without  the  need  for  preventive  maintenance  or 
system  calibration,  except  at  system  startup,  shall  be  supported  by  the  system. 


2.6.2  Initialization  and  Coordinate  System  Requirements 

Initialization  and  maintenance  of  a  referential  coordinate  system  will  require  that: 

1.  The  Marine  Corp  Units  utilizing  the  system  are  following  the  “Rule  of  Three”  structure  (Figure  2). 

Assumptions 

•  Three  men  to  a  fire  team  commanded  by  a  Corporal  (so  there  are  actually  a  total  of  four  on  the 
team,  when  you  count  the  team  leader).  Three  fire  teams  to  a  rifle  squad  commanded  by  a 
sergeant.  Three  rifle  squads  to  a  platoon  commanded  by  a  Lt.  Three  rifle  platoons  to  a 
company  commanded  by  a  Capt.  Three  companies  to  a  battalion  commanded  by  a  Lt  Col.,  etc. 
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Figure  2:  Network  and  Clique  Structure 


•  Team  (Fire  Team):  Four  individual  Marines  assigned  to  a  specific  team  (Three  team 
members,  plus  the  team  leader).  4 

•  Squad:  Three  Teams  are  assigned  to  a  specific  squad.  13 

•  Platoon:  Three  squads  are  usually  assigned  to  a  specific  platoon.  40 

•  Company  (or  Battery):  Three  platoons  are  assigned  to  a  Company  (sometimes  called  a 
battery).  The  Company/battery  is  the  lowest  level  of  command  with  a  headquarters  element 
(example,  a  Company  Commander,  or  Company  First  Sergeant).  121 

•  Battalion:  Three  companies/batteries  are  assigned  to  form  a  battery  a  battalion. 

•  Regiment:  Three  battalions  form  a  Regiment  (Sometimes  called  a  Brigade). 

•  Division:  Three  Regiments  (Brigades)  are  assigned  to  make  up  a  Division. 

•  Marine  Corps:  Three  or  more  divisions  make  up  the  Marine  Corps. 

2.  A  minimum  of  3  resources  will  be  required  to  establish  a  2D  relative  coordinate  system. 

3.  A  minimum  of  4  resources  will  be  required  to  establish  a  3D  relative  coordinate  position. 

4.  The  maximum  clique  size  will  be  50  resources  or  a  platoon. 

5.  The  recon  or  rifle  platoons  will  plan  a  mission  prior  to  committing  resources  to  the  field,  the  plans 
will  include  a  starting  position  for  each  unit  and  the  area  of  operation  will  be  defined  on  a  common 
map.  Landmarks  and  waypoints  will  be  defined  and  provided  during  mission  planning,  and  these 
shall  be  used  to  enhance  the  system  position  accuracy. 

6.  It  is  possible  that  no  GPS  signal  will  be  available  during  system  initialization  and  the  system  will 
have  to  be  initialized  using  a  relative  coordinate  system.  The  relative  coordinate  system  will  be 
maintained  via  fusion  of  position  data  from  RF  Multi-lateration  and  INS;  the  relative  values  will 
be  utilized  until  an  absolute  coordinate  reference  can  be  used. 


7.  If  GPS  is  available  and  4-12  satellites  are  viewable,  the  system  can  be  initialized  using  the  GPS 
position  (known  lat/long  coordinate  starting  position).  The  absolute  coordinate  structure  will  be 
maintained  via  fusion  of  position  data  from  GPS,  INS  and  RF  Multi-Lateration  sources. 


Navigation  in  a  GPS  Denied  Environment  System  Requirement  Specification  9 

Unlimited/Unclassified 

Use  or  disclosure  of  data  contained  on  this  page  is  subject  to  the  restriction(s)  in  the  Confidentiality  Statement  of  this  document. 


®NR 


MERCURY 

42M  Beectwood  Owe.  Suite  105  •  Greensboro,  NC  27410 
Toll-free  800-SS7-63H 


8.  All  systems  within  a  given  clique  or  operating  environment  utilize  a  common  time  mark  or  UTC 
time  value.  The  systems  will  not  need  to  be  calibrated  or  synchronized  in  the  field  due  to 
availability  of  network  timing  clocks  and  communication  algorithms. 

9.  Logistics  Processing  Required  prior  to  fielding  the  system: 

•  Each  system  will  have  a  unique  ID,  Mac  Address,  and/or  IP  Address  that  can  be  used  to 
identify  and  communicate  with  that  system. 

•  Each  node  user  will  be  assigned  an  ID  when  they  arrive  within  the  theatre  of  operations.  This 
ID  will  also  be  utilized  in  the  visualization  component  to  identify  a  particular  resource  on  the 
GUI  map. 

•  A  table  of  “neighbors”  or  ranging  partners  will  be  setup  via  the  logistics  network  interface  / 
processes  prior  to  deploying  the  system  to  the  field.  Maximum  number  of  ranging  partners 
will  be  10,  and  minimum  number  will  be  3  partners. 

2. 6. 3  Relative  Position  Accuracy  Assumptions 

In  order  to  achieve/maintain  the  relative  position  accuracy  requirement,  it  is  assumed  that: 

1.  At  least  three  (3)  members  of  the  clique  will  operate  within  the  RF  position  sensor’s  range. 

2.  Only  legged  motion  (e.g.  walking,  running,  climbing,  etc.)  is  exercised  when  the  system  is  relying 
on  the  INS  /  RF  TOA  Ranging  fused  position  data  for  tracking  (infers  that  GPS  is 
unavailable/unreliable  and  RF  Non-LOS  conditions  exist). 


2. 6. 4  Absolute  Position  Accuracy  Assumptions 

In  order  to  achieve/maintain  absolute  position  accuracy,  it  is  assumed  that: 

1.  GPS  will  be  available  at  least  during  mission  start/device  initialization;  or 

2.  A  Landmark-based,  calibrated  map  with  position  metadata  will  be  available  at  least  during  mission 
start/device  initialization. 

3  Conditions  and  Constraints 


3.1  Environmental  Conditions 

No  environmental  conditions  have  been  explicitly  expressed  in  the  ONR  BAA;  hence,  following  conditions 
are  not  system  requirements.  However,  the  following  list  was  taken  from  Solicitation  No.  HDTRA1-05-R- 
0005  entitled  Global  Positioning  System  -  Denied  Navigation  and  Mapping  due  to  its  relevance  to  the 
solution  defined  herein.  These  conditions  should  be  targeted  as  closely  as  possible  and  are  included  here  to 
serve  as  a  guideline  during  the  design  and  development  of  the  system  final  form  factor,  for  phase  1  they 
should  be  viewed  as  future  system  enhancements. 

1.  Operating  Temperature  Range  =  0  to  120  degrees  F. 

2.  Storage  Temperature  Range  =  -10  to  130  degrees  F. 

3.  Waterproof  and  submersible  to  3  feet  for  10  minutes. 

4.  Operational  reliability  not  less  than  (NLT)  95%  following  exposure  to  an  8  hour  MIL-STD  810E 
Salt/Fog  and  Sand/Dust  test  or  industry  equivalent  standard. 

5.  No  parts  breakage  or  system  degradation  following  NLT  3  drops  from  different  orientations  in 
accordance  with  MIL-STD-33  IB  Five  Foot  Drop  Test  or  equivalent  industry  standard. 

6.  Operational  reliability  NLT  95%  following  exposure  to  a  30  minute  MIL-STD  810E  Loose  Cargo 
Vibration  Test  or  equivalent  industry  standard. 
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3.2  Constraints 

The  following  constraints  are  based  on  statements  found  in  the  BAA,  responses  to  BAA  FAQs  and  physical 
constraints  of  the  proposed  system  components: 

•  The  system  must  operate  over  an  8  hour  period  with  a  single  charge  of  a  BA-5590  battery. 

•  The  system  must  maintain  a  25  meter  Spherical  Error  Probability  (SEP)  over  the  8  hour  period  and 

over  a  range  of  10km. 

•  The  entire  clique  will  be  operating  within  a  2km  area  over  the  10km  range. 

•  The  entire  system  shall  weigh  1kg  (2.2  lb)  or  less,  not  including  battery. 

•  The  system  size  shall  be  400  cm3  (24.4  in3)  or  less,  not  including  battery. 

•  If  required  no  more  than  3  relays  can  be  utilized  to  support  operation  in  underground  or  cave  like 
environments. 

•  The  system  shall  not  have  access  to  GPS  during  the  8  hour  period. 

•  The  system  shall  be  worn  on  the  users  torso  and  remain  in  a  fixed  position  (especially  during 

system  initialization  and  auto  calibration)  throughout  the  8  hour  operation  period. 


4  Functional  /  Performance  Requirements 


4.1  RF  Communications  and  TOA  GEO-Location 

4.1.1  Mobile  A  d-Hoc  Network  (MANE T) 

(a)  Transceiver  architecture 

•  Transceivers  must  fulfill  two  functions  -  provide  range/position  of  ranging  partners  and 
maintain  network  connectivity. 

•  Transceivers  must  perform  the  function  of  position  references  (beacons)  and  communications 
data  relays  (multi-hop  network  connectivity): 

o  Transceivers  used  as  references/data  relays  must  be  tamper  and  spoof  proof, 

o  Transceivers  used  as  references/data  relays  must  be  expendable. 

o  Transceivers  used  as  references/data  relays  must  support  a  data  interface  that  allows 
simple/autonomous  position  (absolute/relative)  initialization. 

o  Transceivers  used  as  beacons/references/data  relays  must  support  ranging  functionality 
amongst  clique  personnel  within  25  meters  (100m  cave-like  environment  potential  worst- 
case  /  3  relays  allowed  =  approx.  25m). 

•  Transceivers  must  have  capability  of  ranging  over  minimum  3  meter  and  maximum  2Km 
range. 

•  Transceivers  must  maintain  network  connectivity  over  2Km  range. 

(b)  Bandwidth  requirements  for  network  communications 

•  Mobile  system  nodes  shall  transmit  three  data  types  - 

o  Range  data  -  Data  generated  while  ranging  with  closest  references  containing  - 

■  ID  of  ranging  partner  -  including  personnel  and  clique  ID. 

■  Range  of  ranging  partner  and  range  accuracy, 
o  Position  information  - 

■  ID  of  personnel  including  clique  ID. 

■  Position  information  generated  by  each  position  sensor  -  INS,  TOA  and  GPS. 

■  This  information  is  transmitted  to  personnel  at  higher  level. 
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o  Other  communication  data  including  text  messages. 

(c)  Multi-hop  localization  requirements 

•  Network  must  support  multi-hop  localization. 

•  Multi-hop  localization  must  provide  network  connectivity  for  data  sharing  and  text 
messaging. 


4.1.2  Data  Exchange 

(a)  Position  information  format  requirements 

•  Position  information  must  be  displayed  as  Latitude/Longitude/Altitude. 

•  Position  information  format  must  stay  consistent  among  all  position  sensors. 

(b)  Data  requirements 

•  Position  information  data  shall  be  stored  in  all  local  nodes  memory,  in  a  database  table 
format. 

•  Database  of  range  and  associated  accuracy  with  several  ranging  partners  must  be  maintained. 

•  Database  of  position  and  associated  accuracy  must  be  maintained  at  every  level  of  clique. 

•  Database  must  differentiate  between  members  of  own  clique  and  other  cliques. 

•  Position  information  format  and  transmit  data  packet  size  must  not  burden  network  during 
network  updates. 


4.1.3  Time-of-Arrival  (TOA) 

(a)  TOA  algorithm  performance  requirements 

•  TOA  algorithms  must  be  capable  of  ranging  in  open  and  underground  and/or  cave-like 
environments. 

•  Network  connectivity  must  not  interfere  with  ranging  activity  (and  vice-versa). 

•  TOA  range  data  accuracy  errors  must  be  small  enough  to  allow  the  overall  system  to  maintain 
or  beat  the  required  25  m  SEP  accuracy. 

•  The  TOA  algorithms  shall  provide  a  minimum  3  range  references  to  support  2D 

ranging/positioning. 

•  The  TOA  algorithms  shall  provide  a  minimum  4  range  references  to  support  3D 

ranging/positioning. 

•  The  TOA  algorithms  shall  automatically  select  and  provide  3-10  range  references  for  each 
system  request  for  range  information. 

•  The  TOA  algorithms  shall  automatically  identify  /  select  ranging  reference  nodes  based  on  a 
set  of  criteria  which  provides  the  most  accurate  /  consistent  ranges  possible. 

•  The  TOA  algorithms  shall  automatically  review  and  discard  range  data  that  does  not  meet  the 
criteria  required  to  support  system  position  accuracy  requirements. 

(b)  TOA  algorithm  computational  requirements 

•  The  TOA  ranging  algorithm  and  associated  waveform  must  be  able  to  resolve  multi-path 
errors  present  in  enclosed  environments. 

•  Multi-path  resolution  must  not  be  resource  intensive  - 

o  Computations  must  not  exceed  sampling  rate  (sampling  rate  <  5  seconds)  to  ensure  real 
time  operation. 
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o  Computations  must  not  require  additional  processing  resources  outside  of  the  RF  signal 
processing  component  of  the  system. 

•  Multi-path  resolution  must  not  interfere  with  network  connectivity. 

(c)  TOA  algorithm  hardware  design  requirements 

•  The  TOA  component  hardware  volume  shall  be  small  enough  to  allow  the  overall  system  to 
be  400  cm3  or  less. 


4.1.4  Multi-later  ation 

(a)  Multi-lateration  requirements 

•  Multi-lateration  processing  is  required  to  generate  a  position  estimate  when  provided  with 
TOA  range  data. 

•  For  2D  ranging/positioning,  the  multi-lateration  must  use  minimum  of  3  references. 

•  For  3D  ranging/positioning,  multi-lateration  must  use  4  references. 

(b)  Multi-lateration  performance  requirements 

•  Multi-lateration  algorithms  must  perform  with  at  least  threshold  accuracy  of  25m  SEP  or 
better. 

•  Multi-lateration  algorithms  must  be  capable  of  threshold  accuracy  in  outdoor,  indoor, 
underground/cave-like  environments. 


4. 1. 5  Transmission  Security 

•  All  RF  data  transmission  must  be  encrypted;  NSA  Suite  B  compliance  is  required. 


4.2  INS  GEO-Location 

•  The  INS  shall  support  all  forms  of  legged  motion  (walking,  running,  climbing,  etc.)  in  all 
directions  (forward,  backward,  sideways,  up/down,  etc.)  in  a  3D  GPS  denied  environment. 

•  The  INS  threshold  tracking  accuracy  shall  be  25  m  SEP  or  better  for  use  between  the  absolute 
position  update  intervals. 

•  The  INS  component  shall  provide  3D  position  information  in  Latitude,  Longitude,  Altitude 
(meters)  at  a  minimum  frequency  of  1  Hz. 

•  The  INS  component  shall  include  an  RS232  data  interface  that  provides  position  and  system 
status  data  as  well  as  supports  3D  position  updates  from  external  position  sensors. 

•  The  INS  component  shall  automatically  initialize  to  the  relative  co-ordinates  of  (0,  0,  0) 
within  5  seconds  after  the  appropriate  power  source  is  connected  to  the  system  and  the  system 
is  switched  on. 

•  The  INS  component  hardware  volume  shall  be  small  enough  to  allow  the  overall  system  to  be 
400  cm3  or  less. 

•  The  placement  of  the  INS  component  on  the  navigating  personnel  shall  not  inhibit  the  user 
from  performing  their  operational  /  tactical  responsibilities  during  mission  activity. 


4.3  Single  Board  Computer  (SBC) 

•  The  SBC  component  shall  automatically  initialize  (complete  the  OS  boot-loading  process  and 
be  ready  for  local  position  initialization)  within  15  seconds  after  the  appropriate  power  source 
is  connected  to  the  system  and  the  system  is  switched  on. 

•  The  SBC  component  hardware  volume  shall  be  small  enough  to  allow  the  overall  system  to  be 
400  cm3  or  less. 
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•  The  placement  of  the  SBC  component  on  the  navigating  personnel  shall  not  inhibit  the  user 
from  performing  their  operational  /  tactical  responsibilities  during  mission  activity. 

•  The  SBC  component  shall  support  data  interfaces  to  the  GPS/INS  (RS232), 
TOA/Communication  (RS232/Ethernet)  and  Military  Radio  (Ethernet)  components. 

•  The  SBC  component  shall  be  able  to  capture  data  from  the  GPS,  INS  and  TOA  components  in 
near  real-time  (data  should  be  captured  with  in  less  than  1  second  for  each  component). 

•  The  SBC  component  shall  support  a  standard  data  /  video  interface  for  host  control  /  display. 

•  The  SBC  component  shall  provide  processing  capability  that  allows  for  the  completion  of  the 
sensor  data  fusion  in  near  real-time  (fusion  process  must  complete  within  5  seconds). 

•  The  SBC  component  shall  support  8  hours  of  continuous  on-board  data  logging/storage 
during  mission  activity. 

•  The  SBC  component  shall  produce  system  logs  of  the  following  mission  data: 

o  Local  User’s  Position  Data 
o  Text  Messages  (sent/received) 
o  System  Errors  /  Alerts 


4.4  GPS 

•  The  placement  of  the  GPS  Receiver  component  shall  not  inhibit  users  from  performing  their 
operational  /  tactical  responsibilities  during  mission  activity. 

•  In  order  to  ensure  tight  package  integration  /  small  form  factor,  the  GPS  receiver  shall  be 
enclosed  along  with  the  other  system  components. 

•  The  placement  of  the  GPS  Antenna  component  on  navigating  personnel  shall  not  inhibit  users 
from  performing  their  operational  /  tactical  responsibilities  during  mission  activity  while 
ensuring  the  highest  possible  reception  of  the  GPS  signal  transmissions. 

•  The  GPS  shall  support  reception  of  the  LI  frequency,  C/A  code  (SPS),  provide  12 
independent  tracking  channels,  and  a  separate  search  &  acquisition  engine. 

•  The  GPS  receiver  shall  provide  support  for  WAAS,  EGNOS,  and  MSAS. 

•  The  GPS  component  shall  provide  A-GPS  and  D-GPS  support. 

•  GPS  component  accuracy  will  be  3m  CEP  (50%)  to  5m  CEP  (95%)  at  velocity  of  0.1  m/s,  and 
time  of  20  ns  RMS. 

•  The  GPS  shall  be  able  to  perform  signal  reacquisition  at  100ms  typical. 

•  The  GPS  Time  to  First  Fix  (TTFF)  for  an  out  of  the  box  start  shall  be  40s  typical;  for  a  cold 

start  shall  be  35s;  and  for  a  hot  start  shall  be  4.5s  minimum. 

•  GPS  sensitivity  acquisition  (cold)  shall  be  at  -141.5  dBm;  acquisition  (hot,  warm)  shall  be  - 
149  dBm;  tracking  (hot,  warm)  shall  be  -156  dBm;  and  navigation  (hot,  warm)  shall  be  -155.5 
dBm. 

•  The  GPS  hardware  shall  work  on  an  operating  voltage  range  of  2.7V  -  3.3VDC. 

•  The  GPS  shall  be  able  to  operate  at  temperatures  -40C  to  +85C. 

•  The  GPS  shall  work  with  an  external,  passive  or  active  antenna,  with  an  input  of  LGA  pad, 
50ohm. 

•  The  GPS  power  consumption  rate  shall  be  95mW  @  2.7V  (Continuous  Mode),  15mW  @ 
2.7V  (Idle  Mode),  and  20pW  @  2.7V  (Sleep  Mode). 

•  The  GPS  component  shall  provide  a  serial  data  interface  (RS232)  that  supports  the  output  of 
position  information  @  minimum  1  Hz  to  a  host  computer. 

•  The  GPS  data  output  format  shall  be  in  line  with  the  NMEA-0183  protocol. 

•  The  GPS  shall  have  an  onboard  16MB  flash  memory,  minimum. 
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•  The  GPS  unit  dimensions  shall  be  22  x  23  x  2.9  mm  or  less  including  RF  shield. 

•  The  GPS  unit  mass  shall  be  3  g  or  less. 


4.5  Fusion  Algorithm 

The  position  fusion  algorithm  is  a  critical  component  of  the  proposed  solution.  The  fusion  algorithm  fuses 
position  information  received  from  different  positioning  systems  -  INS,  Velocimeter,  GPS,  TOA, 
Pseudolites,  LORAN,  etc.  positioning  systems.  Afore-mentioned  positioning  systems  are  composed  of  one 
or  more  sensors  (see  Figure  3)  that  have  inherent  inaccuracies  over  distance  traveled,  time  or  area  of 
operation.  The  fusion  algorithm  must  provide  the  best  estimate  of  position  in  presence  of  these 
inaccuracies.  The  fusion  algorithm  is  a  statistical  tool  that  reduces  noise  (inaccuracy)  of  the  position 
information  acquired  from  the  position  sensors  and  provides  the  best  position  estimate. 

•  The  fusion  algorithm  shall  utilize  a  Kalman  Filter,  which  includes  system  state  estimation  and 
Kalman  gain  estimation  processes. 

•  Mobility  models  of  each  position  sensor  must  be  generated  and  verified. 

•  Models  will  be  expressed  as  either  regression  (uni/multi-variate)  or  as  polynomials. 

•  Mobility  model  determines  linearization  process  of  mobility  model  of  each  position  sensor. 

o  Polynomials  can  be  linearized  by  smoothing,  or  other  forms  of  low  pass  filtering  of 
process  data. 

o  Regression  variates  can  be  linearized  by  differentiation  of  the  process  data. 

•  Variables  critical  to  position  estimation  other  than  position  information  such  as  velocity, 
acceleration,  etc.  must  be  identified,  placed  and  updated  in  the  system  state  matrix. 

•  Standard  deviation  (o)  of  position  estimates  must  have  an  SEP  of  25m  or  less. 

•  Round  off  errors  during  computation  of  Kalman  filter  gain  must  be  reduced  by  matrix 
factorization. 

•  Use  of  Reset/Reinitialize  feedback  loop  design  parameters  must  be  defined 
o  Time  of  operation  - 

■  INS  systems  drift  with  time  and  will  be  reset  with  the  fused  position 
(Reset/Reinitialize  Loop) 

■  The  time  of  reset  will  be  obtained  after  testing  of  the  INS  systems 

o  RF  range/position  estimate  data  shall  include  an  accuracy  estimate.  If  accuracy  does  not 
conform  to  the  SEP  requirements,  fusion  algorithm  will  reset  the  TOA  ranging 
component  using  available  fused  position. 

4.6  Mobility  Estimation 


4. 6. 1  Mobility  Estimation  Requirements  -  INS  GEO-Location 

•  Mobility  model  must  represent  position  information  with  the  least  error  (minimum  squared 
error  (MSE)  or  least  squared  error  (LSE)). 

•  Mobility  model  must  model  process  noise  and  measurement  noise. 

4.6.2  Mobility  Estimation  Requirements  -  TOA  GEO-Location 

•  To  calculate  a  2D  position  estimate  the  RF  Positioning  system  requires  a  minimum  of  3 
reference  nodes. 

•  To  calculate  a  3D  position  estimate  the  RF  Positioning  system  requires  a  minimum  of  4 
reference  nodes. 

•  The  Mobility  model  must  represent  position  infonnation  with  least  error  (minimum  squared 
error  (MSE)  or  least  squared  error  (LSE)). 
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•  Mobility  model  must  model  process  noise  and  measurement  noise. 

•  Modeling  of  the  RF  Positioning  variables  will  be  required  in  order  to  provide  the  most 
accurate  position  calculation  processing. 


4.7  Referential  Coordinate  System 

•  Initialization  process  must  be  autonomous  requiring  minimal  human  intervention. 

•  Initialization  must  commence  on  power  on. 

•  Preference  must  be  given  to  GPS/global  coordinate  system. 

•  If  neither  coordinates  are  available  then  setting  up  local  coordinate  system  must  commence. 

•  Local  coordinate  system  origin  must  be  the  highest  ranked  personnel  in  ranging  distance. 

•  Minimum  3  personnel  required  for  2D  positioning,  4  personnel  for  3D  positioning. 

•  Neighbor  table  must  be  initiated  while  forming  the  local  coordinate  system. 

•  Coordinate  system  transformations  must  be  recorded  in  coordinate  transformation  table. 

•  Upon  arriving  in  ranging  distance  of  higher  ranked  personnel,  local  coordinate  system  must  be 
transformed  to  higher  ranked  personnel’s  coordinate  system. 

•  Coordinate  transformation  must  be  made  backward  compatible  -  i.e.  position  information  in  the 
older  coordinate  system  must  be  transformed  to  newer  coordinate  system  to  permit  personnel  to 
track  back  to  original  path  if  necessary. 

•  As  a  future  enhancement  the  system  shall  be  capable  of  identifying  clique  members  from 
visitors. 

•  The  assimilation  process  shall  have  a  manual  interface  to  allow  verification  of  the  assimilation 
task  prior  to  adding  a  visitor  to  the  local  system  neighbor  table. 

4.8  Visualization 

4. 8. 1  Auto-calibration  / System  initialization  Status  Display  requirements 

During  the  auto-calibration  /  system  initialization  process  the  status  bar  indicator  and  text  fields 
will  be  utilized  to  indicate  current  system  status.  The  indicator  area  /  field  will  be  red  during  Start¬ 
up,  Initialization,  or  Coordinate  System  Initialization.  Text  values  will  be  displayed  in  the  status 
text  field.  The  status  indicator  field  will  turn  green  after  the  coordinate  system  initialization 
process  has  completed,  the  status  text  field  will  provide  details  on  the  status  of  the  system 
including  -  INS  only,  INS/TOA,  TOA  Only  or  GPS. 

4.8.2  Network  Health  display  requirements 

The  Network  Connectivity  field  in  the  Status  Bar  will  be  utilized  to  display  the  RF  IP  Based 
Tactical  Internet  Link  network  connectivity  based  on  data  provided  by  the  CMR. 

4. 8. 3  Position  Accuracy  display  requirements 

The  Accuracy  indicator  /  Figure  of  Merit  (FOM)  field  will  be  used  to  display  position  accuracy. 
The  Spherical  Error  Probability  (SEP)  shall  be  used  to  populate  this  field.  The  displayed  value 
will  be  in  meters  and  will  correspond  to  the  calculated  value  from  the  position  fusion  process. 

4.8.4  Pre-mission  configuration  requirements 

A  list  of  clique  members  who  will  support  each  mission  shall  be  identified  and  their  node 
information  shall  be  added  to  the  system  configuration  file  and  installed  into  the  system  nodes  by 
the  logistics  user.  The  configuration  file  data  will  be  utilized  to  populate  the  neighbor  table.  The 
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neighbor  table  shall  be  utilized  by  the  system  to  identify  ranging  partners  for  each  node  within  the 
clique,  identify  group  hierarchy  for  each  node  within  the  clique  and  role  of  node  (end  user  or 
beacon).  The  data  will  be  entered  into  a  comma  delimited  text  files  and  the  data  will  be 
downloaded  into  the  node  memory  location.  The  configuration  files  will  be  specific  to  each 
mission  plan  and  shall  include  a  list  of  clique  members,  their  assigned  node  ID,  pre-canned  text 
message  content,  a  list  of  map  files,  clique  structure  and  A-GPS  data.  This  configuration  file  will 
then  be  loaded  into  each  system  node  where  the  data  will  be  added  to  the  local  copy  of  the 
neighbor  table.  The  following  fields  will  be  available  for  population: 

•  SID 

•  UID 

•  Resource  Type 

•  Text  Messages  (canned) 

•  Maps  (location) 

The  remainder  of  the  data  in  the  memory  location  will  be  loaded  into  the  UI  via  the  system  startup/ 
initialization,  local  coordinate  initialization  and  position  fusion  processes.  Please  review  the 
appropriate  area  of  this  document  for  further  details  on  those  processes. 


4. 8. 5  Minimum  /  Optimal  Visualization  Requirements 

•  The  user  interface  shall  include  an  auto-calibration  /  system  initialization  status  in  the  status 
bar  section  of  the  display. 

•  The  user  interface  shall  include  a  network  connectivity  status  in  the  status  bar  section  of  the 
display. 

•  The  user  interface  shall  include  a  position  accuracy  value  in  the  status  bar  section  of  the 
display. 

•  The  user  interface  shall  provide  a  page  to  support  the  text  messaging  feature. 

•  The  user  interface  main  page  shall  be  the  map  display  screen  and  shall  provide  a  means  to 
change  the  map  displayed  on  the  screen. 

•  The  user  interface  shall  provide  a  means  to  manually  set  user  position  by  selection  of  a  point 
on  the  map  displayed  on  the  main  UI  screen. 

The  list  below  indicates  features  or  functions  that  are  not  necessary  for  the  basic  functionality  of 
the  system  but  will  be  targeted  as  system  enhancements  to  improve  the  user’s  capabilities  or 
provide  additional  functionality  beyond  that  originally  requested  by  the  ONR  project  definition. 
These  items  will  be  targeted  for  inclusion  in  Phase  2  deliverables  based  on  feedback  from  the  user 
community  and  time  available  for  development  of  the  associated  functionality. 

•  The  user  interface  End  User  Task  bar  features,  shall  include  the  following  features  as  a 
future  system  enhancement;  Measure  Distance,  and  Bearing  To  functions. 

•  The  user  interface  shall  be  upgraded  in  the  future  to  provide  a  Logistic  /  Configuration 
user  interface  enhancement.  For  phase  2  prototype  the  project  the  configuration  file  can 
be  produced  and  loaded  manually. 

4.9  Ease  of  Use 

4. 9. 1  Auto  -  calibration  /System  initialization  requirements 

The  TrakPoint  application  /  system  software  will  be  updated  to  include  an  auto-calibration  and 
system  initialization  procedure.  The  procedure  will  allow  the  system  end  user  to  just  power-on  the 
system  node  and  the  system  will  visually  display  when  it  is  ready  for  resource  tracking  /  end  user 
navigation.  Previously  the  system  would  require  user  interface  with  data  entry  prior  to  the  system 
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being  ready  for  navigation.  Specific  system  requirements  for  the  auto-calibration  /  system 
initialization  procedures  can  be  found  in  the  Initialize  and  Maintain  a  Referential  Coordinate 
system  section  of  this  document. 

4. 9.2  Clique/Group  auto  assignment  process  requirements 

As  part  of  the  pre-deployment  mission  configuration  file  setup,  the  hierarchy  of  each  clique  shall 
be  defined  and  entered  in  to  the  local  version  of  the  neighbor  table  in  every  node  that  will  be 
deployed  with  a  dismounted  rifleman.  This  table  shall  automatically  allow  the  individual  system 
nodes  to  identify  the  other  nodes  within  their  range  that  are  a  part  of  their  clique  or  group.  See  the 
Visualization  section  of  this  document  for  more  details  on  the  neighbor  table,  configuration  file 
and  clique  assignment  processes.  For  the  process  requirements  associated  with  the  transition  from 
one  clique  to  another  see  the  Clique  Assimilation  section  of  this  document. 

4. 9. 3  Startup  requirements  for  identifying  relative  remote  user  positioning 

See  the  Referential  Coordinate  System  section  of  this  document  for  a  description  of  the  processes 
and  related  requirements  for  identification  of  relative  remote  user  positioning.  This  section  will 
provide  details  on  how  each  user  node  position  is  identified  and  how  that  data  is  shared  with  the 
other  members  of  the  clique  or  remote  users.  Post  identification  of  each  node’s  (user’s)  position, 
the  data  shall  be  stored  in  a  neighbor  table  which  shall  be  stored  locally  on  each  node  and  shared 
with  other  nodes  within  range.  This  information  shall  be  updated  as  new  information  is  received 
form  other  resources.  The  local  neighbor  table  data  shall  be  used  to  display  the  position  of  all 
nodes  /  resources  on  the  local  Map  UI.  All  position  data  shall  be  forwarded  to  C2  for  a  Situational 
Awareness  display  that  can  be  utilized  by  supervisory  resources. 

4.10  Communications  Processes 

4.10.1  Multi-hop  Localization 

The  communication  system  shall  support  shared  position  awareness  of  all  clique  personnel  by 
“hopping”  through  intermediary/relay  nodes,  when  direct  communication  links  are  unavailable 
and  Non-LOS  conditions  exist. 

4.10.2  Locating  Beacons 

(a)  Deployment  Requirements 


•  The  system  nodes  shall  provide  a  dual  role;  they  shall  support  the  mobile  users  and  shall 
provide  a  hardware  component  that  can  be  utilized  as  a  stationary  beacon. 

•  The  Beacon  configuration  shall  be  supported  by  the  use  of  the  set  position  UI  feature. 
See  the  Visualization  section  of  this  document  for  details  on  the  UI  features. 

•  When  in  the  beacon  mode  the  system  nodes  must  meet  all  network  functionality 
requirements  including  data  connectivity  and  TOA  ranging. 

•  The  system  nodes  hardware  configuration  will  be  the  same  whether  used  as  a  mobile 
tracking  device  or  as  a  system  location  beacon,  on/off  switch,  zeroize  button,  external 
connections,  etc... 

•  The  system  nodes  shall  support  standard  operations  including  auto-initialize  (OS, 
communication  /  ranging  processes)  within  1  minute  of  being  turned  on,  when 
functioning  in  the  beacon  mode. 

•  The  system  nodes  while  in  beacon  mode  shall  automatically  join  the  communication 
network  and  assimilate  into  the  local  coordinate  system  (show  up  accurately  on  the  clique 
members’  map)  of  the  clique  to  which  it  has  been  assigned. 
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(b)  Spoof-Proofing  Requirements 

The  beacon  operating  mode  shall  provide  a  method  to  ensure  authenticity  /  data  and  position 
validity  during  mission  operation. 

(c)  Position  Reference  /  Initialization 

After  power  is  supplied  to  the  beacons,  they  shall  automatically  establish  communication  with 
the  clique  and  assimilate  into  the  local  coordinate  system.  In  addition  to  the  ad-hoc  method  of 
initialization,  a  logistics  resource  shall  be  able  to  establish  the  initialization  parameters  via  the 
system  pre-mission  configuration  process  by  editing  the  configuration  file  on  a  local 
command  and  control  computer  and  transferring  it  via  a  USB  memory  device  or  wireless 
network  to  the  system  node.  The  configuration  file  shall  specify  that  the  device  is  to  initialize 
based  upon  the  provided  values  rather  than  by  the  default  auto-initialization  process.  An 
additional  method  shall  be  available  wherein  any  clique  member  can  initialize  the  beacon 
manually  in  the  field.  After  placing  the  beacon  in  the  desired  location,  turning  it  on,  and 
establishing  communications,  the  clique  member  shall  be  able  to  mark  the  beacon  location  via 
the  set  position  UI  feature. 

4.10.3  Text  Messaging 

(a)  Interface  Requirements 

•  The  UI  component  shall  provide  a  messaging  interface  that  allows  the  clique  personnel  to 
send  short  text-based  pre-canned  messages  to  other  clique  members  through  the  MANET. 

•  At  minimum,  text  messages  shall  consist  of  the  following  fields: 

o  Sender  ID 

o  Sender  Name 

o  Send  Time 

o  Message  Data 

•  Maximum  Data  packet  size  shall  be  1500  bytes. 

•  A  log  of  sent  and  received  messages  shall  be  stored  on  each  personnel  member’s  local 
computer  unit;  the  log  shall  be  accessible  for  review  by  clique  personnel  through  the  UI 

•  The  UI  shall  provide  a  means  for  the  message  recipient  to  acknowledge  the  message. 

•  At  minimum,  the  log  shall  consist  of  the  following  fields: 

o  Sender  ID 

o  Sender  Name 

o  Send  Time 

o  Received  Time 

o  Message  Data 

(b)  Canned  Message  Requirements 

•  The  pre-mission  configuration  file  shall  support  a  method  of  defining,  editing  and 
downloading  predefined  messages  to  all  system  nodes  prior  to  deployment  in  order  to 
save  data  entry  time  for  common  communication  tasks. 

4.10.4  Clique  Assimilation 

Blue  force  tracking  capability  is  necessary  to  prevent  fratricide.  To  provide  blue  force  tracking, 
systems  must  be  capable  of  tracking  members  within  the  clique  as  well  as  members  from  other 
cliques.  In  extreme  cases  where  a  member  of  another  clique  is  lost  or  out  of  range  of  his  own 
clique  after  deployment,  another  clique  shall  possess  the  capability  to  assimilate  the  lost  personnel. 
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A  technique  to  ensure  that  this  process  of  assimilating  new  members  into  the  clique  remains 
spoof-proof  shall  be  devised.  The  assimilation  technique  shall  ensure  that  only  valid  members  of 
other  cliques  are  assimilated  by  using  a  form  of  key  exchange.  Since  all  personnel  will  be 
equipped  with  encrypted  communications  channels,  personnel  may  be  equipped  with  special  keys 
for  clique  assimilation.  The  clique  member  who  is  not  associated  with  a  given  clique  shall 
automatically  exchange  these  special  keys  when  within  range  of  the  target  wireless  network  island. 
The  key  exchange  shall  alert  clique  members  of  presence  of  member  of  another  clique  in  the 
vicinity.  When  key  exchange  is  completed  successfully,  the  non  aligned  resource  shall  be 
assimilated  into  the  clique. 

4.10.5  Military  Radio 

The  primary  purpose  of  the  military  radio  component  is  to  provide  clique  position  information  and 
mission  status  updates  to  a  TOC  over  a  long-haul  wireless  connection.  Currently,  one  military 
radio  is  deployed  per  platoon/clique  (40  men)  and  is  normally  utilized  by  the  platoon  leader.  All 
position  information  applicable  to  the  platoon/clique  shall  be  funneled  through  this  link  in  order  to 
be  visualized,  analyzed,  and  reviewed  at  the  TOC  /  C2  level. 

A  table  that  reflects  the  platoon’s  operational  status  and  situational  awareness  shall  be  maintained 
by  the  system  nodes  and  platoon  leader  hardware.  Periodic  updates  to  this  table  (at  least  1  update 
every  5  minutes)  shall  be  received  from  the  squad  and  fire-team  levels,  when  connectivity  is 
available.  Whenever  an  update  has  been  made  to  the  table  that  results  in  an  overall  change  of  the 
table  state,  an  exchange  process  shall  be  initiated  and  executed  between  the  platoon  leader’s 
system  (via  the  military  radio  connection)  to  the  TOC  /  C2. 

The  connection  to  the  military  radio  component  is  either  Ethernet  or  Serial.  For  additional 
information,  please  refer  to  “WSRT  Quick  Reference  Guide  6-9-06.pdf’  and  the  MDS-SR 
Interface  Control  Documentation  for  the  mechanical,  electrical,  and  data  interface  requirements 
for  the  Military  Radio  component. 

4.11  Performance  and  Cost  Requirements 

4.11.1  Requirements  for  evaluation  of  cost  vs.  performance  based  on  system  configuration 

Based  on  the  system  requirements,  data  will  need  to  be  captured  to  enable  evaluation  of  cost 
verses  performance. 

When  multiple  components  or  processes  are  identified  the  engineers  will  need  to  capture  technical 
requirements  and  cost  information  from  the  component  vendor  to  determine  which  product  will 
best  suit  the  needs  of  the  project.  The  information  captured  during  these  efforts  will  be  utilized  to 
develop  the  Cost  verses  Performance  matrix. 

To  ensure  the  data  is  meaningful  the  difference  between  component  or  procedures  will  have  to 
classified,  the  difference  may  be  cost,  performance,  speed,  capacity,  volume,  processing  power, 
time  required  to  develop  /  implement,  etc.  See  the  next  section  for  data  that  should  be  gathered  for 
generation  of  a  Cost  verses  Performance  Matrix. 

4.11.2  Requirements  for  a  Cost  vs.  Performance  Matrix 

The  following  data  shall  be  collected  to  populate  the  Cost  verses  Performance  Matrix.  External 
data  including  component  technical  specification  sheets  and  back  up  documentation  should  also  be 
captured  to  ensure  there  is  enough  material  to  evaluate  the  best  solution  for  the  cost.  See  the 
spreadsheet  named  “Cost2Performance.xls”;  this  document  template  will  be  utilized  to  generate 
the  matrix. 

•  Item  #  -  this  field  is  the  item  number  from  I  to  oo,  this  is  just  a  place  holder  for  tracking  a 


given  item. 
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•  System  Feature  /  Component  -  this  field  should  be  used  to  identify  the  system  feature  or 

component  that  is  impacted  by  the  item(s)  that  will  be  described  on  this  line.  Allows  the 

reader  to  determine  priority  for  implementation. 

•  Description  of  Item  -  provide  a  brief  description  of  the  hardware  /  software  component, 
process,  procedure  or  algorithm.  If  this  is  a  COTS  item  the  manufacturer  and  part  number 
should  also  be  provided. 

•  Item  Cost  -  the  cost  of  the  item  for  a  single  item  and  for  volumes  of  100,  500,  and  1000.  If 
this  is  a  process,  procedure  or  algorithm  that  must  be  created  /  constructed  internally  this 
should  be  a  cost  estimate  based  on  limited  requirements  /  design  definition.  The  cost  estimate 
approach  used,  calculations  along  with  high  level  design  definition  should  be  included  in  the 
associated  documentation. 

•  Performance  Category  -  this  field  should  be  a  drop  down  list  of  values  like,  cost, 

performance,  speed,  capacity,  volume,  processing  power,  time  required  to  develop  / 

implement,  etc. . .  The  complete  list  will  be  developed  as  data  is  collected. 

•  Explanation  of  Performance  Improvement  -  provide  a  brief  description  of  how  the 
component  can  improve  the  performance  of  the  system  and  why  you  feel  this  is  a  valid 
improvement,  tech  specs,  prior  exposure  or  utilization  of  the  item,  etc. . . 

•  Notes  -  provide  any  additional  notes  that  can  be  beneficial  in  determining  implementation 
priority. 

•  Location  of  Associated  Documentation  -  provide  a  fill  UNC  defined  path  to  the  location  of 
any  supporting  documentation  along  with  a  name  of  the  document. 


4.11.3  Minimum/ Optimal  Performance  and  Cost  Requirements 

The  minimal  Performance  vs.  Cost  requirements  will  be  the  generated  and  shall  be  accompanied 
by  delivery  of  the  cost  to  performance  matrix  at  the  end  of  phase  2.  The  delivery  of  the  matrix  will 
be  followed  by  a  review  and  recommendation  of  next  steps  with  the  ONR  program  management 
team  and  system  end  users.  The  matrix  shall  identify  opportunities  for  improvements  in  system 
functionality,  based  on  cost,  to  target  future  system  enhancements.  These  items  shall  be 
prioritized  for  inclusion  in  future  releases  of  the  production  units  as  a  means  to  provide  continual 
improvement  of  product  functionality. 

4.12  System  Security 


4.12.1  Communication  Security 

All  cryptographic  operations  to  secure  both  data  at  rest  and  in  transit  shall  meet  all  Suite  B  security 

requirements. 

Elements  of  SUITE  B  include  - 

•  Encryption:  Advanced  Encryption  Standard  (AES)  -  FIPS  197  (with  keys  sizes  of  128  and  256 
bits)  -  http://csrc.nist.gov/publications/fips/fipsl97/fips-197.pdf, 

•  Digital  Signature:  Elliptic  Curve  Digital  Signature  Algorithm  -  FIPS  186-2  (using  the  curves  with 
256  and  384-bit  prime  moduli)  -  http://csrc.nist.gov/publications/fips/fipsl86-2/fipsl86-2- 
changel.pdf, 

•  Key  Exchange:  Elliptic  Curve  Diffie-Hellman  or  Elliptic  Curve  MQV  Draft  NIST  Special 
Publication  800-56  (using  the  curves  with  256  and  384-bit  prime  moduli)  - 
http://csrc.nist.gov/CryptoToolkit/kms/kevschemes-Jan03.pdf, 

•  Hashing:  Secure  Hash  Algorithm  -  FIPS  180-2  (using  SHA-256  and  SHA-384)  - 
http://csrc.nist.gOv/publications/fips/fipsl80-2/fipsl80-2withchangenotice.pdf. 

For  more  information  on  Suite  B:  http://www.nsa.gov/ia/industrv/crypto  suite  b.cfm?MenuID=10.2.7. 
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4.12.2  Physical  Security 


The  physical  enclosure  for  each  system  component  shall  implement  measures  that  deter  immediate 
access  to,  tampering  with,  or  destruction  of  internal  hardware  components  by  unauthorized  personnel. 


4.12.3  Data  Access  /  Storage  Security 

A  zeroize  function  shall  be  available  to  erase  all  volatile  and  non-volatile  data  for  each  system 
component  in  order  to  disable  /  prevent  unauthorized  access  to  confidential  mission  information.  As  a 
future  enhancement  a  user  verification  procedure  shall  be  employed  at  system  start-up  in  order  to 
ensure  access  to  authorized  personnel. 

4.13  Information  Management 

4.13.1  Mission  Data 

The  following  data  shall  be  stored  on  each  user’s  system  in  a  secure  directory  (encryption  may  be 
necessary)  in  order  to  accurately  initialize  for  a  mission  as  well  as  to  reproduce  and  replay  a  mission  in 
its  entirety: 

•  Scenario  File 

•  Position  Log 

•  Message  Log 

•  Error  Log 

•  Map(s) 

•  AGPS  Data  File 

5  Interface  Requirements 

This  clause  contains  the  specification  of  requirements  for  interfaces  among  different  components.  Any 
interdependencies  or  constraints  associated  with  the  interfaces  are  identified  (e.g.,  communication 
protocols,  special  devices,  standards,  fixed  formats).  Each  interface  may  represent  a  bidirectional  flow  of 
information.  A  graphic  representation  of  the  interfaces  is  used  (Figure  3). 

5.1  IMU-GPS/INS  Interface 

The  IMU  and  INS  mechanical  and  electrical  interface  will  be  SPI  compliant. 

5.1.1  IMU  Input 

The  IMU  component  shall  provide  the  GPS/INS  fusion  pre-processor  with  the  following  data,  at  minimum: 

■  Raw  Magnetometer  Data 

o  X-axis  component 

o  Y-axis  component 

o  Z-axis  component 

■  Raw  Accelerometer  Data 

o  X-axis  component 

o  Y -axis  component 

o  Z-axis  component 

■  Raw  Angular  Rate  Data 

o  X-axis  component 

o  Y -axis  component 
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o  Z-axis  component 

■  Temperature  of  the  interior  of  the  IMU  (if  an  IMU  enclosure  is  used) 


5.2  Barometer-GPS/INS  Interface 

The  Pressure  sensor  and  GPS/INS  mechanical  and  electrical  interface  will  be  SPI  compliant. 


5. 2. 1  Barometer  Input 

The  Barometer  component  shall  provide  the  GPS/INS  fusion  pre-processor  with  the  following  data,  at 
minimum: 

■  Pressure 

■  Temperature 

5.3  Velocimeter-GPS/INS  Interface 

The  Velocimeter  and  INS  mechanical  and  electrical  interface  will  be  SPI  or  RS232  compliant. 


5. 3. 1  Velocimeter  Input 

The  Velocimeter  shall  provide  the  GPS/INS  fusion  pre -processor  with  the  following  data,  at  minimum: 
■  Velocity 
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Figure  3:  System  Interfaces. 
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5.4  GPS/INS-SBC  Interface 


The  GPS  and  SBC  mechanical  and  electrical  interface  will  be  RS232  compliant.  The  NMEA-0183  data 
interface  standard  will  be  followed.  Proprietary  message  formats  that  meet  the  NMEA-0183  standard  are 
acceptable. 


5.4.1  GPS/INS  Input 

The  GPS/INS  component  shall  provide  the  SBC  with  the  following  RMC,  GGA,  GSA,  and  GSV  sentence 
data,  at  minimum: 

■  UTC  Fix  Time 

■  Position  Information 

o  Latitude 

o  Longitude 

o  HDOP/VDOP/PDOP 

o  Altitude  (meters  above  sea  level) 

o  Height  of  geoid  (mean  sea  level)  above  WGS-84  ellipsoid 

■  Speed  over  ground  (m/s) 

■  Magnetic  Variation 

■  Satellite  Information 

o  Number  of  satellites  in  view 

o  Satellite  PRN  number 

o  Elevation  (degrees) 

o  Azimuth  (degrees) 

o  Signal  strength 

o  Fix  Quality  (0  -  Invalid,  1  -  GPS  Fix,  2  -  DGPS  Fix) 

■  System  related  status  /  error  messages 

■  System  parameter  configurability  (baud  rate,  etc.) 

5.4.2  GPS/INS  Output 

The  GPS/INS  component  shall  accept  the  following  data  from  the  SBC,  at  minimum: 

■  Position  Update  /  Override  Information 

o  Latitude 
o  Longitude 
o  HDOP/VDOP/PDOP 
o  Altitude  (meters  above  sea  level) 

5.5  TOA-SBC  Interface 

The  TOA  and  SBC  mechanical  and  electrical  interface  will  be  RS232  compliant.  The  message  structure 
and  their  protocols  follow  ICD-GPS-150.  Refer  to  “ICD_v7  4_modified  for  MDS_SR.doc”  for  additional 
information. 


5.5.1  TOA  Input 

The  TOA  component  shall  provide  the  SBC  with  the  following  data,  at  minimum: 

■  TOA  Ranging  Data  (Ranging  Partner  Specific) 
o  ID 
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5.5.2  TOA  Output 

The  TOA  component  shall  accept  the  following  data  from  the  SBC,  at  minimum: 

■  System  Status 

o  Status  of  GPS  and  INS 
o  Navigation  FOM 

■  Navigation  Solution  and  Guidance  Data 

o  Position  Information  (WGS-84) 

■  Latitude 

■  Longitude 

■  Altitude 

o  ENU  Velocity  (Velocity  in  East,  North,  and  Up  coordinates) 
o  Position  and  Velocity  Variances 
o  PVT  Time 

5.6  Communication-SBC  Interface 

The  Communication  and  SBC  mechanical  and  electrical  interface  will  be  either  Ethernet  or  RS232 
compliant.  The  radio  shall  support  Ethernet  or  PPP  interface  for  data.  Using  a  serial  connection  shall 
require  configuration  of  the  SBC  for  Point-to-Point  Protocol  (PPP).  For  additional  information,  please  refer 
to  “WSRT  Quick  Reference  Guide  6-9-06.pdf’.  The  following  data  will  be  shared  over  this  interface: 

■  Clique-wide  SVT  updates 

■  Clique  Text  Messages 

■  Mission  Data 

5.7  Military  Radio/Auxiliary  CMR-SBC  Interface 

The  Military  Radio/Auxiliary  CMR  and  SBC  mechanical  and  electrical  and  data  interface  will  be  Ethernet 
compliant.  The  following  data  will  be  shared  over  this  interface: 

■  Clique  and  C2  Text  Messages 

■  Clique  Positions  to  C2 

■  Mission  Data  to/from  C2 
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6.2  Verification  Requirements 

The  table  below  provides  the  verification  objectives  that  will  be  utilized  to  verify  the  requirements  within 
this  document.  These  objectives  will  be  used  as  a  basis  for  development  of  unit,  integration,  system  and 
acceptance  test  cases  that  will  be  executed  during  the  product  test  cycles.  Content  may  be  added  or 
removed  based  on  changes  to  the  requirements,  design  and/or  testing  activities.  Where  differences  exist 
between  the  content  below  and  the  content  of  the  Test  Plans,  Designs,  and  Cases  (all  phase  2  deliverables), 
the  test  documentation  will  take  precedence.  The  requirements  coverage  matrix  will  ensure  that  all  system 
requirements  /  functionality  have  test  coverage.  The  Requirement  ID  is  associated  with  hidden  text  tags 
within  the  body  of  the  document  that  are  present  at  the  beginning  of  each  associated  requirement  statement. 


Table  1  -  Verification  Objectives  Table 


Requirement 

ID 

Verification  Requirement 

SyRSl 

Verify  that  the  system  mobile  nodes  include  a  GPS  component,  an  INS  component,  an  RF 
Communication  and  TOA  Ranging  component,  a  GEO-Location  Core  Processing  Unit,  and 
a  Display  Interface. 

SyRS2 

Verify  that  the  position  estimation  system  GEO-Location  Core  provides  I/O  access  to  the 
various  local  position  sensors  and  shall  implement  advanced  fusion  algorithms  in  order  to 
produce  an  enhanced  local  position  estimate  based  upon  the  data  available  from  the  various 
position  sensors. 

SyRS3 

Verily  that  the  mobile  system  node  fused  position  estimate  is  viewable  by  all  mobile  users 
via  a  simple  graphical  display. 

SyRS4 

Verify  that  position  data  is  encrypted  with  NS  A  Suite  B  compatible  data  security  before  it 
is  transmitted  to  the  clique  network  or  C2. 

SyRS5 

Verify  that  the  system  mobile  nodes  can  receive  position  data  from  members  on  the  clique 
network  or  from  beacons. 

SyRS5 

Verify  upon  receipt  of  position  data  the  system  nodes  will  decrypt  the  data,  determine  data 
reliability,  and  fuse  reliable  data  with  the  local  position  estimate  to  improve  local  position 
accuracy. 

SyRS6 

Verify  that  system  nodes  can  transmit/share  position  data  between  clique  resources  and  C2. 

SyRS6 

Verily  that  all  user  position  data  is  present  on  the  system  display  unit. 

SyRS7 

Verify  that  text-based  data  transfer  is  provided  by  the  mobile  system  nodes  to  provide 

Short  Message  Service  within  the  clique. 

SyRS8 

Verify  that  the  mobile  tracking  system  nodes  provide  an  indication  of  current  mode  of 
operation  in  the  visual  display. 

SyRS8a 

Verify  that  the  system  nodes  can  operate  providing  accurate  position  estimates  when  in 

GPS  Enabled  mode  and  that  the  proper  mode  is  displayed  on  the  UI. 

SyRS8b 

Verify  that  the  system  nodes  can  operate  providing  accurate  position  estimates  when  in 

GPS  Restricted  mode  and  that  the  proper  mode  is  displayed  on  the  UI. 

SyRS8c 

Verify  that  the  system  nodes  can  operate  providing  accurate  position  estimates  when  in 

GPS  Denied  mode  and  that  the  proper  mode  is  displayed  on  the  UI. 

SyRS9 

Verify  that  the  system  UI  provides  sensor  and  network  status. 

SyRS9a 

Verify  that  the  system  UI  displays  the  appropriate  position  sensors  status  when  the 
following  sensors  are  in  use  for  providing  position  estimates:  GPS,  INS,  TOA,  and 
degraded/unreliable. 

SyRS9b 

Verify  that  the  system  UI  displays  state  of  the  network  link  and  provides  accurate  status 
when  the  network  is:  Connected,  Degraded,  or  Disconnected 

SyRSlO 

Verify  that  personnel  tracking  system  nodes  can  maintain  a  position  accuracy  of  25m  SEP 
over  8  hours  an  a  distance  of  lOKm. 

SyRSll 

Verify  that  the  system  nodes  utilize  a  multi-sensor  positioning  system  which  is  initialized 
by  an  absolute  source  and  aided  by  advanced  sensor  fusion  algorithms. 

SyRSl  2 

Verify  that  when  GPS  is  denied  to  the  system  nodes  at  mission  initiation,  the  system  will 
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Requirement 

ID 

Verification  Requirement 

establish  an  alternate  referential  coordinate  system  for  use  in  clique  position  tracking. 

SyRS13 

Verify  when  the  system  node  starting  coordinates  are  established  via  GPS;  that  an 
independent  referential  coordinate  system  relative  to  the  starting  coordinates  shall  be 
established  and  maintained  throughout  the  mission  operation. 

SyRS14 

Verify  that  throughout  the  8  hour  mission  period  every  clique  member  is  able  to  self 
localize  their  own  position  and  to  visualize  the  positions  of  all  team  members. 

SyRS15 

Verify  that  the  system  nodes  can  maintain  an  alternate  coordinate  system  that  can 
supersede  divergences  among  position  estimates. 

SyRS16 

Verify  that  the  system  can  establish  and  distribute  relative  positions  of  all  clique  personnel 
that  minimizes  divergences  among  individually  localized  position  estimates. 

SyRS17 

Verify  that  the  system  utilizes  two-way  TOA  ranging  techniques  to  establish  /  maintain  the 
alternate  referential  coordinate  system  and  provide  a  mobile  ad  hoc  network. 

SyRS18 

Verify  that  the  system  incorporates  the  use  of  a  distributed  voting  algorithm  process  to 
maintain  the  integrity  of  the  referential  coordinate  system;  to  reconcile  divergences  among 
clique  position  estimates;  and  to  disseminate  a  converged  clique  position  estimate. 

SyRS19 

Verify  that  post  creation  of  the  alternate  coordinate  system  the  tracking  device  are  able  to 
survive  any  single  point  of  failure,  including  support  for  cross  network  data  replication  and 
automated  failover  support  among  focal  nodes. 

SyRS20 

Verify  that  the  system  nodes  include  a  lightweight,  easy  to  use  graphical  user  interface. 

SyRS21 

Verify  that  the  system  nodes  provide  every  system  user  a  UI  that  provides  visualization  of 
the  relative  positions  of  other  clique  personnel  even  if  their  individually  localized  position 
relative  to  a  starting  point  has  been  lost. 

SyRS22 

Verify  that  the  system  nodes  provide  every  system  user  the  ability  to  visualize  other  clique 
personnel  and  locate  the  distance  and  orientation  to  each. 

SyRS23 

Verify  that  the  system  nodes  provide  every  system  user  has  the  ability  to  visualize 
parameters  for  position  estimate  precision,  network  connectivity,  and  beacon  locations. 

SyRS24 

Verify  that  the  system  node  UI  provides  every  system  user  the  ability  to  interact  with  Short 
Message  Service. 

SyRS25 

Verify  that  the  system  node  UI  enables  the  system  user  to  visually  identify  members  of 
other  cliques  as  they  approach  and  are  within  range  of  the  local  mobile  adhoc  network. 

SyRS26 

Verify  that  system  provides  mobile  adhoc  network  capabilities  that  support  autonomous 
sharing  of  personnel  positioning  information. 

SyRS27 

Verify  that  system  nodes  can  be  utilized  as  beacons  to  augment  accurate  positioning  and  to 
extend  communication  range  for  NLOS  conditions. 

SyRS28 

Verify  that  the  system  provides  a  simple  method  to  initialize  nodes  operating  as  beacons  / 
display  beacon  ID  /  coordinates;  and  that  these  nodes  can  be  used  to  support  RF  TOA 
ranging. 

SyRS29 

Verify  that  the  system  nodes  incorporate  cryptographic  logic  which  provides  security  for 
data  at  rest  and  in  transit  while  meeting  Suite  B  security  requirements. 

SyRS30 

Verify  that  the  system  nodes  support  limited  text-based  messaging  /  Short  Message  Service 
between  clique  personnel,  and  clique  groups. 

SyRS31 

Verify  that  the  system  provides  a  method  to  identify  /  share  user  position  data  when  the 
boundaries  between  cliques  intersect  and  that  the  positions  of  Marines  within  the 
intersecting  area,  from  both  cliques,  are  displayed  to  all  system  users  within  range. 

SyRS32 

Verify  that  the  system  provides  a  means  to  assimilate  Marines  within  the  intersecting 
clique  area  into  the  coordinate  reference  system  of  the  destination  clique. 

SyRS33 

Verify  that  system  provides  a  means  for  the  destination  clique  to  acknowledge  the 
hierarchy  /  identity  of  the  Marine,  and  the  Marine's  relative  position  is  disseminated 
throughout  the  destination  clique. 

SyRS34 

Verify  that  the  system  provides  a  method  to  permanently  assimilate  the  Marine  into  the 
destination  clique. 
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SyRS35 

Verify  that  when  clique  intersection  incidents  occur  the  system  provides  a  means  to  avoid 
friendly  fire  by  making  the  position  data  distribution  and  assimilation  processes  simple  to 
implement. 

SyRS36 

Verily  that  the  system  provides  a  functional  standard  military  radio  interface. 

SyRS37 

Verify  that  the  prototype  system  nodes  require  minimal-to-no  user  training  and  that  the 
system  UI  requires  minimal  user  interaction  for  operation. 

SyRS38 

Verify  that  the  system  initialization  processes  is  automated,  executing  to  establish  the 
user's  position  when  the  node  is  powered  on. 

SyRS39 

Verify  that  system  node  GUI  features  are  easy  to  use  and  that  they  do  not  distract  the 
mobile  user  from  their  mission  duties. 

SyRS40 

Verify  that  the  automated  processes  facilitate  geo-location  of  beacons  based  upon  the  user's 
coordinates  and  the  TOA  measurements  between  the  user's  system  and  the  placement  of  the 
beacon. 

SyRS41 

Verify  that  system  node  position  accuracy  in  a  GPS-denied  environments  is  be  25m  SEP  or 
better  after  eight  hours  of  operation. 

SyRS42 

Verify  that  the  system  node  volume  is  400  cm3  (24.4  inches3)  or  less. 

SyRS43 

Verify  that  the  system  node  components  total  mass  is  1kg  or  less,  not  including  battery. 

SyRS44 

Verify  that  the  system  nodes  operate  for  8  hours  (or  more)  upon  recharge  from  a  single 
BA5590  battery  (170  WH)  capacity. 

SyRS45 

Verily  that  the  individual  system  node  estimated  production  cost  in  quantity  of  1000  is 
$2000  USD  or  less. 

SyRS46 

Verify  that  MDS  produces  and  delivers  a  minimum  of  five  (5)  positioning  system  nodes  at 
the  end  of  Phase  II. 

SyRS47 

Verify  that  if  the  system  utilizes  relays  to  meet  the  system  capabilities  a  maximum  of  three 
(3)  additional  nodes  will  be  produced  and  delivered  at  the  end  of  Phase  II. 

SyRS48 

Verify  that  system  user  roles  are  based  on  functional  responsibilities  for  the  system  end 
user  and  that  there  is  no  restricted  access  to  the  UI  features  based  on  role. 

SyRS49 

Verify  that  the  Logistics  support  resources  can  utilize  a  wireless  network  connection  to 
access/download  the  system  data  to  support  system  pre-mission  configuration,  ensure  the 
logistics  user  does  not  require  access  to  the  UI  unless  he  is  testing  the  unit  post 
maintenance  or  repair  activities. 

SyRS50 

Verify  that  the  Logistics  user  can  establish  clique  node  identification,  create  data  for 
ranging  partner  tables,  communications  channels  /  partners  for  text  messaging,  select 
mission  maps  for  the  clique,  and  setup  each  system  node  prior  to  node  mission  deployment. 

SyRS51 

Verify  that  the  system  provides  a  means  for  the  Logistics  user  to  provide  pre-configuration 
data,  setup  the  location  beacons,  and  Assisted  GPS  data  for  the  Area  of  Operation. 

SyRS52 

Verify  that  the  system  provides  users  the  means  to  configuration  /  deploy  fixed  position 
beacons,  assimilate  of  new  clique  members  and  send  position  data  to  C2  via  the  military 
radio  interface. 

SyRS53 

Verify  that  system  provides  the  user  will  the  ability  to  enable  the  remote  system  zeroize 
feature. 

SyRS54 

Verify  that  system  provides  the  user  access  to  all  system  features  and  that  all  features 
present  function  as  designed. 

SyRS55 

Verify  that  all  system  users  have  access  to  the  map  user  options  including:  map  selection, 
measuring  distance/angle,  system  zeroize  local  and  remote. 

SyRS56 

Verify  that  the  system  can  generate  a  2D  relative  coordinate  system  with  a  minimum  of  3 
system  nodes. 

SyRS57 

Verify  that  the  system  can  generate  a  3D  relative  coordinate  system  with  a  minimum  of  4 
system  nodes. 

SyRS58 

Verify  that  system  can  provide  network  connectivity  and  position  tracking  for  a  maximum 
of  50  clique  resources  or  an  entire  platoon. 
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SyRS59 

Verify  that  the  system  provides  a  means  for  mission  operations  landmarks  and  waypoints 
to  be  added  to  maps  and  that  these  items  can  be  utilized  by  the  system  user  to  update  their 
position  to  provide  an  accurate  position  estimate. 

SyRS60 

Verify  that  the  system  can  be  initialized  on  a  relative  coordinate  structure  when  no  GPS 
signal  is  available. 

SyRS61 

Verify  that  the  system  use  a  process  called  position  fusion  to  maintain  the  relative 
coordinate  structure  using  data  from  RF  Multi-lateration  and  INS;  ensure  the  system 
overrides  the  relative  values  when  an  absolute  position  data  can  be  received  by  the  system 
node. 

SyRS62 

Verify  that  the  system  fusion  process  can  maintain  absolute  coordinate  structure  using  data 
from  GPS,  INS  and  RF  Multi-Lateration  sources. 

SyRS63 

Verify  that  the  system  nodes  overcome  the  need  for  calibration  /  synchronization  in  the 
field  via  the  use  of  network  timing  clocks  and  communication  algorithms. 

SyRS64 

Verify  that  each  system  node  has  a  unique  ID,  Mac  Address,  and/or  IP  Address  that  can  be 
used  to  identify  and  communicate  with  that  system. 

SyRS65 

Verify  that  every  node  users  ID  is  utilized  in  the  visualization  component  to  identify  a 
particular  resource  on  the  GUI  map. 

SyRS66 

Verify  that  the  system  table  of  "neighbors"  or  ranging  partners  can  be  setup  via  the 
logistics  network  interface  /  processes  prior  to  deploying  the  system  to  the  field;  ensure  the 
system  supports  the  use  of  a  minimum  of  3  and  a  maximum  of  10  ranging  partners. 

SyRS67 

Verify  that  the  system  requires  a  minimum  of  3  clique  members  operating  within  the  RF 
position  sensor's  range  to  calculate  a  position  estimate  via  trilateration. 

SyRS68 

Verify  that  the  system  can  produce  an  accurate  INS  /  RF  TOA  Ranging  fused  position 
estimate  for  all  legged  motion  (e.g.  walking,  running,  climbing,  etc.). 

SyRS69 

Verify  that  the  system  nodes  are  functional  over  an  operating  temperature  range  of  0  to  120 
degrees  F. 

SyRS70 

Verify  that  the  system  nodes  can  withstand  a  storage  temperature  range  of  -10  to  130 
degrees  F,  without  negative  impact  on  system  operation. 

SyRS71 

Verify  that  the  system  nodes  are  waterproof  and  submersible  to  3  feet  for  10  minutes. 

SyRS72 

Verify  that  system  node  operational  reliability  is  not  less  than  95%  following  exposure  to 
an  8  hour  MIL-STD  810E  Salt/Fog  and  Sand/Dust  or  industry  equivalent  standard  test. 

SyRS73 

Verify  that  the  system  nodes  experience  no  parts  breakage  or  system  degradation  following 
NLT  3  drops  from  different  orientations  in  accordance  with  MIL-STD-33  IB  Five  Foot 

Drop  or  equivalent  industry  standard  test. 

SyRS74 

Verify  that  system  nodes  maintain  or  exceed  an  operational  reliability  NLT  95%  following 
exposure  to  a  30  minute  MIL-STD  810E  Loose  Cargo  Vibration  or  equivalent  industry 
standard  test. 

SyRS75 

Verify  that  the  system  nodes  support  operation  over  an  8  hour  period  with  a  single  charge 
of  a  BA-5590  battery. 

SyRS76 

Verify  that  the  system  nodes  are  capable  of  maintaining  a  25  meter  SEP  over  the  8  hour 
period  and  over  a  range  of  10km. 

SyRS77 

Verify  that  all  system  components  weigh  1kg  (2.2  lb)  or  less,  not  including  battery. 

SyRS78 

Verify  that  the  volume  of  all  system  components  are  400  cm3  (24.4  in3)  or  less,  not 
including  battery. 

SyRS79 

Verify  that  they  system  requires  no  more  than  3  relays  to  support  operation  in  underground 
or  cave  like  environments  for  a  range  of  up  to  100  meters. 

SyRS80 

Verify  that  the  system  can  provide  accurate  position  estimates  without  access  to  GPS  over 
an  8  hour  period. 

SyRS81 

Verify  that  the  system  CMR  component  provides  range/position  of  ranging  partners  and 
network  connectivity. 

SyRS82 

Verify  that  the  system  CMR  component  can  function  as  position  references  (beacons)  and 
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communications  data  relays  to  provide  multi-hop  network  connectivity. 

SyRS83 

Verify  that  when  the  system  CMR  component  is  used  as  references/data  relays  they  are 
tamper  and  spoof  proof. 

SyRS84 

Verify  that  when  the  system  CMR  component  is  used  as  references/data  relays  that  they  are 
expendable. 

SyRS85 

Verify  that  when  the  system  CMR  component  is  used  as  references/data  relays  the  GUI 
provides  an  interface  that  allows  simple/autonomous  position  (absolute/relative) 
initialization. 

SyRS86 

Verify  that  when  the  system  CMR  component  is  used  as  beacons/references/data  relays 
they  provide  ranging  functionality  amongst  clique  personnel  within  25  meters  minimum, 
verify  that  longer  and  shorter  ranges  between  nodes  to  not  inhibit  system  capabilities. 

SyRS87 

Verify  that  the  system  CMR  components  are  capable  of  ranging  over  minimum  3  meter  and 
maximum  2Km  range. 

SyRS88 

Verify  that  the  system  CMR  component  can  maintain  network  connectivity  over  2Km 
range. 

SyRS89 

Verify  that  mobile  system  nodes  can  transmit  three  data  types  -  range  data,  position 
information  and  text  messages. 

SyRS89a 

Verify  that  the  system  range  data  includes  the  ID  of  ranging  partner  (personnel  and  clique 
ID),  range  of  ranging  partner(s),  and  range  accuracy. 

SyRS89b 

Verify  that  the  system  position  information  includes  the  ID  of  personnel  including  clique 

ID,  position  data  from  the  INS,  TOA  and  GPS  sensors  and  that  this  information  is 
transmitted  to  the  entire  clique. 

SyRS89c 

Verify  that  the  system  can  support  communication  of  text  messages. 

SyRS90 

Verify  that  the  system  network  component  supports  multi-hop  localization. 

SyRS91 

Verify  that  the  system  network  multi-hop  localization  processes  provide  network 
connectivity  for  data  sharing  and  text  messaging. 

SyRS92 

Verify  that  the  system  position  estimate  is  displayed  in  the  UI  as 

Latitude/Longitude/ Altitude. 

SyRS93 

Verify  that  the  system  position  estimate  format  is  consistent  among  all  position  sensors. 

SyRS94 

Verify  that  the  system  position  estimate  is  stored  in  all  local  nodes  memory,  in  a  database 
table  format. 

SyRS95 

Verify  that  the  system  position  database  includes  range  and  associated  accuracy  of  all 
clique  members  and  that  the  data  is  updated  /  maintained  over  the  entire  8  hour  operational 
period. 

SyRS96 

Verify  that  the  system  position  database  is  maintained  within  every  clique  node. 

SyRS97 

Verify  that  the  system  position  database  can  differentiate  between  members  of  own  clique 
and  other  cliques. 

SyRS98 

Verify  that  the  system  position  data  format  and  transmit  data  packet  size  do  not  burden  the 
network  during  data  distribution  activities. 

SyRS99 

Verify  that  the  system  TOA  algorithms  are  capable  of  ranging  in  open  and  underground 
and/or  cave-like  environments. 

SyRSlOO 

Verify  that  the  system  network  connectivity  does  not  interfere  with  ranging  activity  (and 
vice-versa). 

SyRSlOl 

Verify  that  the  system  nodes  TOA  range  data  accuracy  errors  are  small  enough  to  allow  the 
overall  system  to  maintain  or  beat  the  required  25  m  SEP  accuracy. 

SyRS102 

Verify  that  they  system  TOA  algorithms  can  generate  a  2D  position  estimate  from  a 
minimum  of  3  range  references. 

SyRS103 

Verify  that  they  system  TOA  algorithms  can  generate  a  3D  position  estimate  from  a 
minimum  of  4  range  references. 

SyRS  1 04 

Verify  that  the  system  TOA  algorithms  automatically  select  and  provide  3-10  range 
references  for  each  system  node  request  for  range  information. 
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SyRS105 

Verify  that  the  system  TOA  algorithms  automatically  identify  and  select  ranging  reference 
nodes  based  on  a  set  of  criteria  which  provides  the  most  accurate  /  consistent  ranges 
possible. 

SyRS106 

Verify  that  the  system  TOA  algorithms  automatically  review  and  discard  range  data  that 
does  not  meet  the  defined  selection  criteria. 

SyRS107 

Verify  that  the  system  TOA  ranging  algorithm  and  associated  waveform  are  able  to  resolve 
multi-path  errors  present  in  enclosed  environments. 

SyRS108 

Verily  that  the  system  Multi-path  resolution  processes  are  resource  intensive  -  ensure  the 
computations  do  not  exceed  sampling  rate  (sampling  rate  <  5  seconds)  for  real  time 
operation  and  that  computations  do  not  require  additional  processing  resources  outside  of 
the  CMR  RF  signal  processing  component  of  the  system. 

SyRS109 

Verily  that  the  system  Multi-path  resolution  processes  do  not  interfere  with  network 
connectivity. 

SyRSllO 

Verify  that  the  TOA  component  hardware  volume  enables  the  overall  system  volume  to  be 
400  cm3  or  less. 

SyRSlll 

Verify  that  the  system  utilizes  Multi-lateration  processing  to  generate  a  position  estimate 
when  provided  with  TOA  range  data. 

SyRS112 

Verify  that  the  system  multi-lateration  processes  can  support  2D  ranging/positioning  with  a 
minimum  of  3  references. 

SyRS113 

Verify  that  the  system  multi-lateration  processes  can  support  3D  ranging/positioning  with  a 
minimum  of  4  references. 

SyRS114 

Verify  that  the  system  Multi-lateration  algorithms  can  maintain  a  threshold  accuracy  of 

25m  SEP  or  better. 

SyRS115 

Verify  that  the  system  Multi-lateration  algorithms  are  capable  of  maintaining  the  threshold 
accuracy  in  outdoor,  indoor,  underground/cave-like  environments. 

SyRS116 

Verify  that  all  system  RF  data  transmission  is  encrypted  and  compliant  with  NSA  Suite  B. 

SyRS117 

Verify  that  the  system  INS  component  supports  all  forms  of  legged  motion  (walking, 
running,  climbing,  etc.)  in  all  directions  (forward,  backward,  sideways,  up/down,  etc.)  in  a 
3D  GPS  denied  environment. 

SyRS118 

Verify  that  the  system  INS  component  threshold  tracking  accuracy  is  25  m  SEP  or  better 
and  is  used  to  track  mobile  users  between  absolute  position  update  intervals. 

SyRS119 

Verify  that  the  system  INS  component  provides  3D  position  information  in  Latitude, 
Longitude,  Altitude  (meters)  at  a  minimum  frequency  of  1  Hz. 

SyRS120 

Verify  that  the  system  INS  component  includes  an  RS232  data  interface  that  provides 
position  and  system  status  data  as  well  as  supports  3D  position  updates  from  external 
position  sensors. 

SyRS121 

Verify  that  the  system  INS  component  automatically  initializes  the  relative  co-ordinates  of 
(0,  0,  0)  within  5  seconds  after  power  is  enabled. 

SyRS122 

Verify  that  the  system  INS  component  hardware  volume  is  small  enough  to  allow  the 
overall  system  volume  to  be  400  cm3  or  less. 

SyRS123 

Verify  that  the  system  INS  component  on  the  mobile  personnel  does  not  inhibit  the  user 
from  performing  their  operational  /  tactical  responsibilities. 

SyRS124 

The  associated  requirement  was  removed  from  the  SyRS  content. 

SyRS125 

Verify  that  the  system  SBC  component  automatically  initializes  (complete  the  OS  boot¬ 
loading  process  and  be  ready  for  local  position  initialization)  within  1 5  seconds  after  the 
power  is  enabled. 

SyRS126 

Verify  that  the  system  SBC  component  hardware  volume  is  small  enough  to  allow  the 
overall  system  volume  to  be  400  cm3  or  less. 

SyRS127 

Verify  that  the  system  SBC  component  does  not  inhibit  the  user  from  performing  their 
operational  /  tactical  responsibilities. 

SyRS128 

Verify  that  the  system  SBC  component  provides  data  interfaces  to  the  GPS/INS  (RS232), 
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TOA/Communication  (RS232/Ethernet)  and  Military  Radio  (Ethernet)  components. 

SyRS129 

Verify  that  the  system  SBC  component  is  able  to  capture  data  from  the  GPS,  INS  and  TOA 
components  in  near  real-time  and  the  data  is  captured  with  in  less  than  1  second  for  each 
component. 

SyRS130 

Verify  that  the  system  SBC  component  provides  a  standard  data  /  video  interface  for  host 
control  /  display. 

SyRS131 

Verify  that  the  system  SBC  component  provides  processing  capability  that  allows  for  the 
completion  of  the  sensor  data  fusion  in  near  real-time  and  the  fusion  process  completes 
within  5  seconds. 

SyRS132 

Verify  that  the  system  SBC  component  supports  8  hours  of  continuous  on-board  data 
logging/storage  during  mission  activity. 

SyRS133 

Verify  that  the  system  SBC  component  generates  system  logs  with  the  following  mission 
data:  Local  User's  Position  Data,  Text  Messages  (sent/received),  System  Errors  /  Alerts 

SyRS134 

Verify  that  the  system  GPS  Receiver  component  does  not  inhibit  users  from  performing 
their  operational  /  tactical  responsibilities. 

SyRS135 

Verify  that  the  system  GPS  receiver  is  enclosed  along  with  the  other  system  components. 

SyRS136 

Verify  that  the  system  GPS  Antenna  does  not  inhibit  users  from  performing  their 
operational  /  tactical  responsibilities  and  that  the  antenna  ensures  reception  of  available 

GPS  signal  transmissions. 

SyRS137 

Verify  that  the  system  GPS  supports  reception  of  the  LI  frequency,  C/A  code  (SPS), 
provides  12  independent  tracking  channels,  and  a  separate  search  &  acquisition  engine. 

SyRS138 

Verify  that  the  system  GPS  receiver  supports  WAAS,  EGNOS,  and  MSAS. 

SyRS139 

Verify  that  the  system  GPS  component  provides  A-GPS  and  D-GPS  support. 

SyRS140 

The  associated  requirement  was  removed  from  the  SyRS  content. 

SyRS141 

Verify  that  the  system  GPS  component  accuracy  is  3m  CEP  (50%)  to  5m  CEP  (95%)  at 
velocity  of  0.1  m/s,  and  time  of  20  ns  RMS. 

SyRS142 

Verify  that  the  system  GPS  is  able  to  perform  signal  reacquisition  at  100ms  typical. 

SyRS143 

Verify  that  the  system  GPS  Time  to  First  Fix  (TTFF)  for  an  out  of  the  box  start  is  40s 
typical;  for  a  cold  start  is  35s;  and  for  a  hot  start  is  4.5s  minimum. 

SyRS144 

Verify  that  the  system  GPS  sensitivity  acquisition  (cold)  is  -141.5  dBm;  acquisition  (hot, 
warm)  is  -149  dBm;  tracking  (hot,  warm)  is  -156  dBm;  and  navigation  (hot,  warm)  is  - 
155.5  dBm. 

SyRS145 

Verify  that  the  system  GPS  hardware  works  on  an  operating  voltage  range  of  2.7V  - 
3.3VDC. 

SyRS146 

Verify  that  the  system  GPS  can  operate  at  temperatures  -40C  to  +85C. 

SyRS147 

Verify  that  the  system  GPS  works  with  an  external,  passive  or  active  antenna,  with  an  input 
ofLGApad,  50ohm. 

SyRS148 

Verify  that  the  system  GPS  power  consumption  rate  is  95mW  @  2.7V  (Continuous  Mode), 
15mW  @  2.7V  (Idle  Mode),  and  20pW  @  2.7V  (Sleep  Mode). 

SyRS149 

Verify  that  the  system  GPS  component  provides  a  serial  data  interface  (RS232)  that 
supports  the  output  of  position  information  @  1  Hz  minimum  to  a  host  computer. 

SyRS150 

Verify  that  the  system  GPS  data  output  format  shall  be  in  line  with  the  NMEA-0183 
protocol. 

SyRS151 

Verify  that  the  system  GPS  has  an  onboard  16MB  flash  memory. 

SyRS152 

Verify  that  the  system  GPS  unit  dimensions  are  22  x  23  x  2.9  mm  or  less  including  RF 
shield. 

SyRS153 

Verify  that  the  system  GPS  unit  mass  is  3  g  or  less. 

SyRS154 

Verify  that  the  system  fusion  algorithm  fuses  position  information  received  from  different 
positioning  systems  -  INS,  Velocimeter,  GPS,  TOA,  Pseudolites,  LORAN,  etc.  positioning 
systems. 

SyRS155 

Verily  that  the  system  fusion  algorithm  provides  the  best  estimate  of  position  in  presence 
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of  component  inaccuracies. 

SyRS156 

Verify  that  the  system  fusion  algorithm  utilizes  a  Kalman  Filter,  including  system  state 
estimation  and  Kalman  gain  estimation  processes. 

SyRS157 

Verify  that  the  system  Position  fusion  mobility  models  are  generated  for  each  position 
sensor. 

SyRS158 

Verify  that  the  system  Position  fusion  mobility  models  are  expressed  as  either  regression 
(unimulti-variate)  or  as  polynomials. 

SyRS159 

Verify  that  the  system  Position  fusion  mobility  model  is  capable  of  determining  the 
linearization  process  of  mobility  model  of  each  position  sensor. 

SyRS160 

Verify  that  the  system  variables  critical  to  position  estimation  are  identified,  placed  and 
updated  in  the  system  state  matrix. 

SyRS161 

Verify  that  the  system  Position  fusion  algorithm  position  estimate  standard  deviation  have 
an  SEP  of  25m  or  less. 

SyRS162 

Verify  that  the  system  Position  fusion  algorithm  rounds  off  errors  created  during 
computation  of  Kalman  filter  gain  are  reduced  by  matrix  factorization. 

SyRS163 

Verify  that  the  system  Position  fusion  algorithm  INS  bias  drift  is  reset  by  the  fused  position 
reset/reinitialize  loop. 

SyRS  1 64 

Verify  that  the  system  Position  fusion  algorithm  RF  range/position  estimate  data  includes 
an  accuracy  estimate  and  that  when  the  accuracy  does  not  conform  to  the  SEP 
requirements,  the  system  fusion  algorithm  will  reset  the  TOA  ranging  component  using 
available  fused  position. 

SyRS165 

Verify  that  the  system  INS  Geolocation  mobility  model  represents  position  information 
with  the  least  minimum  squared  error  (MSE)  or  least  squared  error  (LSE). 

SyRS  166 

Verify  that  the  system  INS  Geolocation  mobility  model  includes  modeling  of  process  noise 
and  measurement  noise. 

SyRS  167 

Verify  that  TOA  Geolocation  RF  Positioning  system  requires  a  minimum  of  3  reference 
nodes  to  calculate  a  2D  position  estimate. 

SyRS  168 

Verify  that  TOA  Geolocation  RF  Positioning  system  requires  a  minimum  of  4  reference 
nodes  to  calculate  a  3D  position  estimate. 

SyRS  169 

Verify  that  the  system  TOA  Geo  location  mobility  model  represents  position  information 
with  the  least  minimum  squared  error  (MSE)  or  least  squared  error  (LSE). 

SyRS  170 

Verify  that  the  system  TOA  Geolocation  mobility  model  provides  for  process  noise  and 
measurement  noise. 

SyRS  171 

Verify  that  TOA  Geolocation  modeling  of  the  RF  Positioning  variables  are  performed  to 
provide  the  most  accurate  position  calculation  processing. 

SyRS  172 

Verify  that  the  system  initialization  process  is  autonomous  requiring  minimal  human 
intervention. 

SyRS  173 

Verily  that  the  system  initialization  commences  at  the  node  power  on. 

SyRS  174 

Verify  that  the  system  give  preference  to  GPS/global  coordinate  system,  when  that  data  is 
available. 

SyRS  175 

Verify  that  when  no  absolute  coordinate  references  are  available  to  the  system,  it 
automatically  establishes  and  maintains  a  local  referential  coordinate  system. 

SyRS  176 

Verify  that  the  local  coordinate  system  origin  must  be  the  highest  ranked  personnel  within 
ranging  distance. 

SyRS  177 

Verify  that  the  system  can  create  a  2D  position  estimate  with  a  minimum  of  3  resources  or 

4  resources  for  3D  positioning. 

SyRS  178 

Verily  that  the  system  neighbor  table  is  initiated  while  forming  the  local  coordinate  system. 

SyRS  179 

Verify  that  the  system  coordinate  transformations  are  recorded  in  coordinate  transformation 
table. 

SyRS  180 

Verify  that  upon  arriving  in  ranging  distance  of  higher  ranked  personnel,  the  system  local 
coordinates  are  transformed  to  higher  ranked  personnel's  coordinate  system. 
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SyRS180a 

Verify  that  the  system  coordinate  transformation  is  backward  compatible  -  i.e.  position 
information  in  the  older  coordinate  system  is  transformed  to  the  newer  coordinate  system 
to  permit  personnel  to  track  back  to  original  path. 

SyRS181 

Verify  that  the  system  is  capable  of  identifying  clique  members  from  visitors. 

SyRS182 

Verify  that  the  system  assimilation  process  has  a  manual  component  for  verification  of  the 
transaction  prior  to  completion. 

SyRS183 

Verify  that  during  the  auto-calibration  /  system  initialization  process  the  system  node  UI 
status  bar  indicator  and  text  fields  indicate  current  system  status. 

SyRS184 

Verify  that  the  system  UI  system  mode  indicator  area  /  field  is  red  during  Start-up, 
Initialization,  or  Coordinate  System  Initialization. 

SyRS185 

Verify  that  system  processing  status  field  displays  text  values  indicating  which  components 
are  in  use  by  the  system. 

SyRS186 

Verify  that  the  system  UI  status  indicator  field  will  turn  green  after  the  coordinate  system 
initialization  process  has  completed,  and  that  the  status  text  field  will  provide  details  on  the 
status  of  the  system  including  -  INS  only,  INS/TOA,  TOA  Only  or  GPS. 

SyRS187 

Verify  that  the  system  UI  network  connectivity  field  in  the  Status  Bar  displays  the  RF  IP 
Based  Tactical  Internet  Link  network  connectivity  based  on  data  provided  by  the  CMR. 

SyRS188 

Verify  that  the  system  UI  accuracy  indicator  /  FOM  field  displays  position  accuracy  or 

SEP. 

SyRS189 

Verily  that  the  system  UI  SEP  value  is  displayed  in  meters  and  corresponds  to  the 
calculated  value  from  the  position  fusion  process. 

SyRS190 

Verily  that  the  system  UI  pre-mission  configuration  process  includes  a  method  to  list 
clique  members  who  support  the  mission  along  with  their  node  information  and  that  this 
data  can  be  added  to  the  system  configuration  file  /  installed  into  the  system  nodes  by  the 
logistics  user. 

SyRS191 

Verify  that  the  system  pre-mission  configuration  file  data  is  utilized  to  populate  the 
neighbor  table. 

SyRS191 

Verify  that  the  system  neighbor  table  is  utilized  by  the  system  to  identify  ranging  partners 
for  each  node  within  the  clique,  identify  group  hierarchy  for  each  node  within  the  clique 
and  role  of  node  (end  user  or  beacon). 

SyRS192 

Verify  that  the  system  configuration  file  data  can  be  entered  into  a  comma  delimited  text 
files  and  downloaded  into  the  node(s)  memory  location. 

SyRS193 

Verify  that  the  system  configuration  files  are  specific  to  each  mission  plan  and  include  a 
list  of  clique  members,  their  assigned  node  ID,  pre-canned  text  message  content,  a  list  of 
map  files,  clique  structure  and  A-GPS  data. 

SyRS194 

Verify  that  the  system  configuration  file  can  be  loaded  into  each  system  node  and  the  data 
is  then  added  to  the  local  copy  of  the  neighbor  table  at  system  start-up. 

SyRS195 

Verify  that  the  system  provides  the  following  fields  for  population  of  the  neighbor  table: 

SID,  UID,  Resource  Type,  Text  Messages  (canned),  and  Maps  (location). 

SyRS196 

Verify  that  the  system  uses  the  remainder  of  the  data  in  the  memory  location  are  present  in 
the  UI  post  system  startup/  initialization,  local  coordinate  initialization  and  position  fusion 
processes. 

SyRS197 

Verify  that  the  system  user  interface  includes  an  auto-calibration  /  system  initialization 
status  in  the  status  bar  section  of  the  display. 

SyRS198 

Verify  that  the  system  user  interface  includes  a  network  connectivity  status  in  the  status  bar 
section  of  the  display. 

SyRS199 

Verify  that  the  system  user  interface  includes  a  position  accuracy  value  in  the  status  bar 
section  of  the  display. 

SyRS200 

Verify  that  the  system  user  interface  provides  a  page  to  support  the  text  messaging  feature. 

SyRS201 

Verify  that  the  system  user  interface  main  page  is  the  map  display  screen  which  provides  a 
means  to  change  the  map  displayed  on  the  screen. 
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SyRS202 

Verify  that  the  system  user  interface  provides  a  means  to  manually  set  user  position  by 
selection  of  a  point  on  the  map  displayed  on  the  main  UI  screen. 

SyRS203 

Verify  that  the  system  user  interface  End  User  Task  bar  features,  include  the  following 
features  as  a  future  system  enhancement;  Measure  Distance,  and  Bearing  To  functions. 

SyRS204 

Verify  that  the  system  user  interface  structure  provides  for  the  inclusion  of  a  Logistic  / 
Configuration  user  interface  enhancement. 

SyRS205 

Verify  that  the  phase  2  prototype  system  nodes  support  a  manual  process  for  creation  and 
installation  of  the  project  the  configuration  file. 

SyRS206 

Verify  that  the  system  application  software  is  updated  to  include  an  auto-calibration  and 
system  initialization  procedure. 

SyRS207 

Verify  that  as  part  of  the  pre-deployment  mission  configuration  file  senip,  the  system 
provides  a  means  to  distribute  the  clique  hierarchy  definition  to  the  local  node  neighbor 
table  for  all  nodes  that  will  be  deployed  with  mission  resources. 

SyRS208 

Verify  that  the  system  neighbor  table  automatically  provides  each  node  with  the  ability  to 
identify  other  nodes  within  RF  range  that  are  a  part  of  their  clique  or  group. 

SyRS209 

Verify  that  the  system,  post  identification  of  each  node's  (user's)  position,  stores  the 
position  data  in  a  neighbor  table  and  that  the  data  is  shared  with  other  nodes  within  range. 

SyRS210 

Verify  that  the  system  neighbor  table  position  information  is  updated  as  new  information  is 
received  form  other  resources. 

SyRS211 

Verify  that  the  system  nodes  local  neighbor  table  data  is  used  to  display  the  position  of  all 
nodes  /  resources  on  the  local  Map  UI. 

SyRS212 

Verify  that  the  system  is  capable  of  forwarding  position  data  is  to  C2  via  a  Military  Radio 
Interface. 

SyRS213 

Verify  that  the  system  communication  network  supports  shared  position  awareness  of  all 
clique  personnel  by  "hopping"  through  intermediary/relay  nodes,  when  direct 
communication  links  are  unavailable  and  Non-LOS  conditions  exist. 

SyRS214 

Verify  that  the  system  node  hardware  can  be  utilized  by  mobile  users  or  as  a  stationary 
beacon. 

SyRS215 

Verify  that  the  system  beacon  configuration  process  is  supported  by  the  use  of  the  set 
position  UI  feature. 

SyRS216 

Verify  that  when  operating  in  the  beacon  mode  the  system  nodes  provide  data  connectivity 
and  TOA  ranging. 

SyRS217 

Verify  that  when  operating  in  the  beacon  mode  the  system  node  hardware  configuration  is 
the  same  whether  used  as  a  mobile  tracking  device  or  as  a  system  location  beacon,  on/off 
switch,  zeroize  button,  external  connections,  etc... 

SyRS218 

Verify  that  when  operating  in  the  beacon  mode  the  system  node  supports  standard 
operations  including  auto-initialize  (OS,  communication  /  ranging  processes)  within  1 
minute  of  being  turned  on,  when  functioning  in  the  beacon  mode. 

SyRS219 

Verify  that  when  operating  in  the  beacon  mode  the  system  nodes  automatically  join  the 
communication  network  and  assimilate  into  the  local  coordinate  system  (show  up 
accurately  on  the  clique  members'  map)  of  the  clique  to  which  it  has  been  assigned. 

SyRS220 

Verify  that  the  beacon  operating  mode  provides  a  method  to  ensure  authenticity  /  data  and 
position  validity  during  mission  operation. 

SyRS221 

Verify  that  when  power  is  supplied  to  the  beacons,  they  automatically  establish 
communication  with  the  clique  and  assimilate  into  the  local  coordinate  system. 

SyRS222 

Verify  that  in  addition  to  the  ad-hoc  method  of  initialization,  a  logistics  resource  is  able  to 
establish  the  initialization  parameters  via  the  system  pre-mission  configuration  process. 

SyRS223 

Verify  that  the  system  configuration  file  specifies  that  a  beacon  device  with  pre¬ 
configuration  data  will  initialize  based  upon  the  provided  values  rather  than  by  the  default 
auto-initialization  process. 

SyRS224 

Verify  that  after  placing  the  beacon  in  the  desired  location,  turning  it  on,  and  establishing 
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communications,  the  clique  member  is  able  to  mark  the  beacon  location  via  the  set  position 
UI  feature. 

SyRS225 

Verify  that  the  system  UI  component  provides  a  messaging  interface  that  allows  the  clique 
personnel  to  send  short  text-based  pre-canned  messages  to  other  clique  members  through 
the  MANET. 

SyRS226 

Verify  that  the  system  text  messages  data  consist  of  the  following  fields:  Sender  ID,  Sender 
Name,  Send  Time,  and  Message  Data. 

SyRS227 

Verify  that  maximum  data  packet  size  for  message  text  transmitted  by  the  system  be  1500 
bytes  or  less. 

SyRS228 

Verify  that  the  system  generates  a  log  of  sent  and  received  messages,  stored  on  each 
personnel  member's  local  computer  unit;  ensure  the  log  is  accessible  for  review  by  clique 
personnel  through  the  UI. 

SyRS229 

Verify  that  the  system  UI  provides  a  means  for  the  message  recipient  to  acknowledge  the 
message. 

SyRS230 

Verify  that  the  system  text  message  log  contains  the  following  fields:  Sender  ID,  Sender 
Name,  Send  Time,  Received  Time,  and  Message  Data. 

SyRS231 

Verify  that  the  system  pre-mission  configuration  file  supports  a  method  of  defining,  editing 
and  downloading  predefined  messages  to  all  system  nodes  prior  to  deployment. 

SyRS232 

Verify  that  the  system  provides  the  capability  to  track  members  within  the  clique  as  well  as 
members  from  other  cliques. 

SyRS233 

Verify  that  the  system  assimilation  process  provides  the  capability  to  assimilate  lost  or 
unattached  clique  personnel. 

SyRS234 

Verify  that  the  system  provides  a  technique  to  ensure  that  the  process  of  assimilating  new 
members  into  the  clique  remains  spoof-proof. 

SyRS235 

Verify  that  the  system  assimilation  technique  ensures  that  only  valid  members  of  other 
cliques  are  assimilated  by  using  a  form  of  key  exchange. 

SyRS236 

Verify  that  the  system  assimilation  provides  a  means  to  ensure  the  clique  member  who  is 
not  associated  with  a  given  clique  automatically  exchanges  special  keys  when  within  range 
of  the  target  wireless  network  island. 

SyRS237 

Verify  that  the  system  assimilation  key  exchange  alerts  clique  members  of  presence  of 
member  of  another  clique  in  the  vicinity. 

SyRS238 

Verily  that  when  the  system  assimilation  key  exchange  is  completed  successfully,  the  non 
aligned  resource  shall  be  assimilated  into  the  clique. 

SyRS239 

Verify  that  the  system  military  radio  component  can  provide  clique  position  information 
and  mission  status  updates  to  a  TOC  over  a  long-haul  wireless  connection. 

SyRS240 

Verify  that  the  system  funnels  all  platoon/clique  position  information  through  the  military 
radio  link  for  transmission  to  TOC  /  C2  level. 

SyRS241 

Verify  that  the  system  includes  a  database  table  that  reflects  the  platoon's  operational  status 
and  situational  awareness  and  is  maintained  by  the  system  nodes/  platoon  leader  hardware. 

SyRS242 

Verify  that  the  system  periodically  updates  to  the  position  information  data  table  at  least 
once  every  5  minutes  as  updates  are  received  from  the  squad  and  fire-team  levels. 

SyRS243 

Verify  that  when  the  system  updates  the  position  data  table  generating  an  overall  change  of 
the  table  state,  an  exchange  process  is  initiated  and  data  is  transmitted  to  TOC/C2  by 
platoon  leader's  node  military  radio  connection. 

SyRS244 

Verify  that  the  system  connection  to  the  military  radio  component  is  either  Ethernet  or 

Serial. 

SyRS245 

Verify  that  when  multiple  components  or  processes  are  identified  for  use  in  the  system, 
technical  data  and  cost  infonnation  are  captured  and  entered  into  the  Cost  verses 

Performance  matrix  for  use  in  determination  of  which  option  will  best  suit  the  needs  of  the 
project. 

SyRS246 

Verify  that  the  Cost  verses  Performance  matrix  provides  fields  to  identify  classification  on 

Navigation  in  a  GPS  Denied  Environment  System  Requirement  Specification  37 

Unlimited/Unclassified 

Use  or  disclosure  of  data  contained  on  this  page  is  subject  to  the  restriction(s)  in  the  Confidentiality  Statement  of  this  document. 


IN3  MERCURY 

42M  Brecfiwood  Dtr*.  Suite  105  •  Greensboro,  N.C  ZMW 
Toll-free  800-557-6374 


www.metalausysconi 

Requirement 

ID 

Verification  Requirement 

the  difference  between  component  or  procedures  such  as,  cost,  performance,  speed, 
capacity,  volume,  processing  power,  time  required  to  develop  /  implement,  etc. 

SyRS247 

Verify  that  the  Cost  verses  Performance  matrix  includes  the  following  data  fields:  Item  #, 
System  Feature  /  Component,  Description  of  Item,  Item  Cost,  Performance  Category, 
Explanation  of  Performance  Improvement,  Notes,  and  Location  of  Associated 
Documentation. 

SyRS248 

Verify  that  the  Cost  verses  Performance  matrix  is  delivered  to  ONR  at  the  end  of  phase  2  to 
identify  opportunities  for  improvements  in  system  functionality,  based  on  cost,  to  target 
future  system  enhancements. 

SyRS249 

Verify  that  the  Cost  verses  Performance  matrix  items  are  prioritized  for  inclusion  in  future 
releases  of  the  production  units  as  a  means  to  provide  continual  improvement  of  product 
functionality. 

SyRS250 

Verify  that  all  system  cryptographic  operations  for  data  at  rest  and  in  transit  meet  all  Suite 

B  security  requirements. 

SyRS251 

Verify  that  the  system  node  physical  enclosure  implements  measures  that  deter  immediate 
access  to,  tampering  with,  or  destruction  of  internal  hardware  components. 

SyRS252 

Verify  that  the  system  provides  a  zeroize  function  to  erase  all  volatile  and  non-volatile  data 
for  each  system  component  in  order  to  disable  /  prevent  unauthorized  access  to  confidential 
mission  information. 

SyRS253 

Verify  that  as  a  future  enhancement,  the  system  incorporates  a  user  verification  procedure 
employed  at  system  start-up  in  order  to  ensure  access  to  authorized  personnel. 

SyRS254 

Verify  that  the  following  data  is  stored  on  each  user's  system  in  a  secure  directory  for  use 
in  system  initialization  and  to  provide  a  means  to  replay  a  mission  in  its  entirety:  Scenario 
File,  Position  Log,  Message  Log,  Error  Log,  Map(s),  and  AGPS  Data  File. 

SyRS255 

Verify  that  the  system  IMU  and  INS  mechanical  and  electrical  interfaces  are  SPI 
compliant. 

SyRS256 

Verify  that  the  system  IMU  component  provides  the  GPS/INS  fusion  pre-processor  with 
the  following  data:  Raw  Magnetometer  Data  (X,  Y,  and  Z-axis),  Raw  Accelerometer  Data 
(X,  Y,  and  Z-axis),  and  Angular  Rate,  (X,  Y,  and  Z-axis),  and  Temperature  of  IMU 
interior. 

SyRS257 

Verify  that  the  system  pressure  sensor  and  GPS/INS  mechanical  and  electrical  interfaces 
are  SPI  compliant. 

SyRS258 

Verify  that  the  system  barometer  component  provides  the  GPS/INS  fusion  pre-processor 
with  the  following  data:  Pressure  and  Temperature. 

SyRS259 

Verify  that  the  system  Velocimeter  and  INS  mechanical  and  electrical  interfaces  are  SPI  or 
RS232  compliant. 

SyRS259a 

The  system  velocimeter  component  provides  the  GPS/INS  fusion  pre -processor  with  the 
following  data:  Velocity 

SyRS260 

Verify  that  the  system  GPS  and  SBC  mechanical  and  electrical  interface  is  RS232 
compliant,  the  NMEA-0183  data  interface  standard  is  followed  and  that  proprietary 
message  formats  that  meet  the  NMEA-0183  standard  are  acceptable. 

SyRS261 

Verify  that  the  system  GPS/INS  component  provide  the  SBC  with  RMC,  GGA,  GSA,  and 
GSV  sentence  data  including:  UTC  Fix  Time,  Position  Information  (Latitude,  Longitude, 
HDOP/VDOP/PDOP,  Altitude  (meters  above  sea  level),  and  Height  of  geoid  (mean  sea 
level)  above  WGS-84  ellipsoid);  Speed  over  ground  (m/s);  Magnetic  Variation;  Satellite 
Information  (Number  of  satellites  in  view,  Satellite  PRN  number,  Elevation  (degrees), 
Azimuth  (degrees),  Signal  strength.  Fix  Quality  (0  -  Invalid,  1  -  GPS  Fix,  2  -  DGPS  Fix)); 
System  related  status  /  error  messages;  and  System  parameter  configurability  (baud  rate, 
etc...). 

SyRS262 

Verify  that  the  system  GPS/INS  component  accepts  the  data  from  the  SBC  including: 
Position  Update  /  Override  Information  (Latitude,  Longitude,  HDOP  /VDOP  /PDOP,  and 
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Altitude  (meters  above  sea  level). 

SyRS263 

Verify  that  the  system  TOA  and  SBC  mechanical  and  electrical  interfaces  are  RS232 
compliant  and  that  the  message  structure  /  their  protocols  follow  ICD-GPS-150. 

SyRS264 

Verify  that  the  system  TOA  component  provides  the  SBC  with  the  following  data:  TOA 
Ranging  Data  /  Ranging  Partner  Specific  (ID,  Range,  Figure  of  Merit  (FOM),  Position 
Information  (WGS-84),  Time  Tag,  and  PVT  Time);  and  TOA  Time  Reference. 

SyRS265 

Verify  that  the  system  TOA  component  accepts  the  following  data  from  the  SBC:  System 
Status  (Status  of  GPS  and  INS,  and  Navigation  FOM);  Navigation  Solution  and  Guidance 
Data  -  WGS-84  Position  Information  (Latitude,  Longitude,  and  Altitude);  ENU  Velocity 
(Velocity  in  East,  North,  and  Up  coordinates);  Position  and  Velocity  Variances;  and  PVT 
Time. 

SyRS266 

Verify  that  the  system  Communication  and  SBC  mechanical  and  electrical  interfaces  are 
either  Ethernet  or  RS232  compliant  supporting  Ethernet  or  PPP  interface  for  data. 

SyRS266 

Verify  that  the  system  communication  and  SBC  interface  provides  the  following  data: 
Clique-wide  SVT  updates,  Clique  Text  Messages,  and  Mission  Data. 

SyRS267 

Verify  that  the  system  Military  Radio/Auxiliary  CMR  and  SBC  mechanical  and  electrical 
and  data  interface  is  Ethernet  compliant  and  the  following  data  is  shared  over  this  interface: 
Clique  and  C2  Text  Messages,  Clique  Positions  to  C2,  and  Mission  Data  to/from  C2. 
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